I'm trying to run a member function in a thread, but I get the error illegal operation on bound member function, I'm not sure what I'm doing wrong. I would like if someone could explain me what I'm doing wrong and why I get this error, and give me an example of how to fix it. The code looks like this:
void GameWorld::SetupWorld()
{
// create the window (remember: it's safer to create it in the main thread due to OS limitations)
RenderWindow window(VideoMode(800, 600), "OpenGL");
// deactivate its OpenGL context
window.setActive(false);
// launch the rendering thread
Thread thread(&Render, &window);//This line gives the error
thread.launch();
}
void GameWorld::Render(RenderWindow* window)
{
Texture texture;
Sprite sprite;
if (!texture.loadFromFile("sprite.png"))
{
}
sprite.setTexture(texture);
// the rendering loop
while (window->isOpen())
{
// clear the window with black color
window->clear(Color::White);
// draw everything here...
window->draw(sprite);
// end the current frame
window->display();
}
}
You have a serious case of undefined behavior from passing a pointer to a local variable to the thread.
Once the function returns, that variable will go out of scope, and the object will be destructed, leaving you with a pointer to unallocated memory.
You also have a problem if the Render function is not static, because non-static member functions have a hidden first argument that becomes the this pointer inside the member function. It's probably this problem that the compiler is complaining about.
A possible third problem might be that once the SetupWorld function returns, your thread variable will also go out of scope and be destructed. Depending on what threading framework you're using it might kill the thread quite unexpectedly.
To fix the compilation error change your complaining line to Thread thread(&GameWorld::Render, &window)
However for completeness you should read #Some programmer dude's answer.
Related
I'm trying to use multiple threads to make one function run concurrently with another, but when the function that the new thread is running uses a static function, it always returns 0 for some reason.
I'm using Boost for the threading, on Linux, and the static functions work exactly as expected when not using threads. I'm pretty sure this isn't a data race issue because if I join the thread directly after making it (not giving any other code a chance to change anything), the problem persists.
The function that the thread is created in:
void WorldIOManager::createWorld(unsigned int seed, std::string worldName, bool isFlat) {
boost::thread t( [=]() { P_createWorld(seed, worldName, isFlat); } );
t.join();
//P_createWorld(seed, worldName, isFlat); // This works perfectly fine
}
The part of P_createWorld that uses a static function (The function that the newly-created thread actually runs):
m_world->chunks[i]->tiles[y][x] = createBlock(chunkData[i].tiles[y][x].id, chunkData[i].tiles[y][x].pos, m_world->chunks[i]);
m_world is a struct that contains an array of Chunks, which has a two dimensional array of Tiles, which each have texture IDs associated with a texture in a cache. createBlock returns a pointer to a new tile pointer, completely initialized. The static function in question belongs to a statically-linked library, and is defined as follows:
namespace GLEngine {
//This is a way for us to access all our resources, such as
//Models or textures.
class ResourceManager
{
public:
static GLTexture getTexture(std::string texturePath);
private:
static TextureCache _textureCache;
};
}
Also, its implementation:
#include "ResourceManager.h"
namespace GLEngine {
TextureCache ResourceManager::_textureCache;
GLTexture ResourceManager::getTexture(std::string texturePath) {
return _textureCache.getTexture(texturePath);
}
}
Expected result: For each tile to actually get assigned its proper texture ID
Actual result: Every tile, no matter the texturePath, is assigned 0 as its texture ID.
If you need any more code like the constructor for a tile or createBlock(), I'll happily add it, I just don't really know what information is relevant in this kind of situation...
So, as I stated before, all of this works perfectly if I don't have a thread, so my final question is: Is there some sort of undefined behaviour that has to do with static functions being called by threads, or am I just doing something wrong here?
As #fifoforlifo mentioned, OpenGL contexts have thread affinity, and it turns out I was making GL calls deeper into my texture loading function. I created a second GL context and turned on context sharing and then it began to work. Thanks a lot, #fifoforlifo!
I am upgrading an application from VC6 to VS2010 (Legacy Code). The application runs as it should in VC6 but after converting the project to VS2010 I encountered some problems.
On exiting the application, the program breaks while attempting to lock on entering a critical section.
The lock count usually alternates from -1(Unlocked) to -2(Locked) but just before the program crashes, the lock count is 0.
g_RenderTargetCriticalSection.Lock();// Breaks here
if (g_RenderTargets.Lookup(this, pRenderTarget))
{
ASSERT_VALID(pRenderTarget);
g_RenderTargets.RemoveKey(this);
delete pRenderTarget;
}
g_RenderTargetCriticalSection.Unlock();
Here is the CCriticalSection::Lock() function where ::EnterCriticalSection(&m_sect); fails. I found it strange that on failing, the lock count changes from 0 to -4??
_AFXMT_INLINE BOOL (::CCriticalSection::Lock())
{
::EnterCriticalSection(&m_sect);
return TRUE;
}
If anyone has encountered anything similar to this, some insight would be greatly appreciated. Thanks in advance.
The comments indicate this is a file-scope object destructor order issue. There are various ways you could address this. Since I haven't seen the rest of the code it's difficult to offer specific advice, but one idea is to change the CS to live in a shared_ptr and have your CWnd hold onto a copy so it won't be destroyed prematurely. e.g.:
std::shared_ptr<CCriticalSection> g_renderTargetCriticalSection(new CCriticalSection());
Then in your window class:
class CMyWindow : public CWnd
{
private:
std::shared_ptr<CCriticalSection> m_renderTargetCriticalSection;
public:
CMyWindow()
: m_renderTargetCriticalSection(g_renderTargetCriticalSection)
{
// ...
}
~CMyWindow()
{
// guaranteed to still be valid since our shared_ptr is keeping it alive
CSingleLock lock(m_renderTargetCriticalSection.get(), TRUE);
// ...
}
// ...
};
The issue was that the application's Main Window was being destroyed after the application's global object was destroyed. This meant that the g_renderTargetCriticalSection was already Null when the main window was trying to be destroyed.
The solution was to destroy the Application's main window before it's global object (CDBApp theApp) calls ExitInstance() and is destroyed.
int CDBApp::ExitInstance()
{
LOGO_RELEASE
//Destroy the Main Window before the CDBApp Object (theApp) is destroyed.
if(m_Instance.m_hWnd)
m_Instance.DestroyWindow();
return CWinApp::ExitInstance();
}
This code doesn't make sense:
int CDBApp::ExitInstance()
{
LOGO_RELEASE
//Destroy the Main Window before the CDBApp Object (theApp) is destroyed.
if(m_Instance.m_hWnd)
m_Instance.DestroyWindow();
return CWinApp::ExitInstance();
}
m_Instance is a handle, not a class, so it can't be used to call functions!
Some of functions in my program needs to run a long time so that the user may interrupted it. The structure is like this:
int MainWindow::someFunc1()
{
//VP is a class defined somewhere.
VP vp1;
//the for loop that needs time to execute.
return 0;
}
int MainWindow::someFunc2()
{
VP vp2;
//another loop that consumes time.
return 0;
}
If the user run the either of functions or at the same time and click exit on the right top, the program will still run in background until the loop is finished. I tried to free the resources in void closeEvent(QCloseEvent *) ：
void MainWindow::closeEvent(QCloseEvent *)
{
vp.stopIt();
}
However since vp1 and vp2 are local variables, I don't know how to pass them into the closeEvent() function and free resources. Any suggestions will be appreciated.
Since the variables are created on the stack, they will be automatically freed in the end of their scope (at the closing } of the function in your case), you don't have to worry about them.
If you want to free them before the function ends, you need to re-implement the functions and probably allocate and free the memory for those variables by yourself, outside of the function. The way you pass them to the functions (either passing them as function arguments, or including them into the class) depends on you.
You can't. You should declare vp1 and vp2 in MainWindow as member variable.
As far as I understood the OP's requirement, he's looking how to interrupt someFunc1 or someFunc2 when the main window is closed.
Those functions run in the GUI thread, so the following statement is a misunderstanding
the program will still run in background until the loop is finished
What actually happens, the program runs until the function is complete, then the user action is processed by the framework. Therefore, when void MainWindow::closeEvent is executed, nothing is running in the background and resources are already freed.
OP should move someFunc1 and someFunc2 to a worker thread.
Theoretically, you might be able to do this using setjmp. Something along these lines:
#include "setjmp.h"
jmp_buf doNotAttempt;
jmp_buf badPractice;
int MainWindow::someFunc1()
{
VP vp1;
for (...) {
// do stuff
if (setjmp(doNotAttempt)) { /*free resources, then: */ longjmp(badPractice,1); }
}
return 0;
}
// [...]
void MainWindow::closeEvent(QCloseEvent *)
{
if (!setjmp(badPractice))
longjmp(doNotAttempt,1);
else
// do the same for your other loop
}
In practice, do not do this - it's a terrible idea for all kinds of reasons. As other folks have said, just declare vp1 and vp2 as member variables.
I have this very annoying issue, whenever i call a function:
void renderGame::renderMovingBlock(movingBlock* blockToRender){
sf::Shape blockPolygon;
sf::Shape blockLine = sf::Shape::Line(blockToRender->getLineBegin().x,blockToRender->getLineBegin().y,blockToRender->getLineEnd().x,blockToRender->getLineEnd().y, 3.f,movingBlockLineColor);
for(auto i = blockToRender->getVertexArray()->begin(); i!=blockToRender->getVertexArray()->end(); ++i){
blockPolygon.AddPoint(i->x, i->y, movingBlockBlockColor);
}
renderToWindow->Draw(blockLine);
renderToWindow->Draw(blockPolygon);
}
Which is a simple function, it takes a pointer to an object and uses SFML to render it on the screen. It's a simple polygon that moves on a rail.
getVertexArray() returns a pointer to the object's vector of vertices, renderToWindow is a pointer to sf::RenderWindow
The very weird issue i have is that i can call this function it won't return from it, VC++ breaks and points me to:
int __cdecl atexit (
_PVFV func
)
{
return (_onexit((_onexit_t)func) == NULL) ? -1 : 0;
}
I'm getting weird behavoir here, i can stop this function right before exiting by calling the Display() function and system("pause"), it'll display everything perfectly fine, but one step further and it breaks.
I'll add that i'm sending a dynamically allocated object, when i set a regular one everything's fine. It's weird, when i debug the program then the polygon and line have the right coordinates, everything displays properly, but it just can't return from the function.
If a function will not return sounds like you messed up the stack somewhere previously - this is most likely an out-of-bounds write.
Or possibly because you are ending up in atexit there could have been an uncaught exception thrown.
Either way - welcome to the joys of programming - now you have to find an error which probably happens long before your function gets stuck
You could try some tools like valgrind (if its available for windows) or some other bounds checkers.
I want to pass some data around threads but want to refrain from using global variables if I can manage it. The way I wrote my thread routine has the user passing in a separate function for each "phase" of a thread's life cycle: For instance this would be a typical usage of spawning a thread:
void init_thread(void *arg) {
graphics_init();
}
void process_msg_thread(message *msg, void *arg) {
if (msg->ID == MESSAGE_DRAW) {
graphics_draw();
}
}
void cleanup_thread(void *arg) {
graphics_cleanup();
}
int main () {
threadCreator factory;
factory.createThread(init_thread, 0, process_msg_thread, 0, cleanup_thread, 0);
// even indexed arguments are the args to be passed into their respective functions
// this is why each of those functions must have a fixed function signature is so they can be passed in this way to the factory
}
// Behind the scenes: in the newly spawned thread, the first argument given to
// createThread() is called, then a message pumping loop which will call the third
// argument is entered. Upon receiving a special exit message via another function
// of threadCreator, the fifth argument is called.
The most straightforward way to do it is using globals. I'd like to avoid doing that though because it is bad programming practice because it generates clutter.
A certain problem arises when I try to refine my example slightly:
void init_thread(void *arg) {
GLuint tex_handle[50]; // suppose I've got 50 textures to deal with.
graphics_init(&tex_handle); // fill up the array with them during graphics init which loads my textures
}
void process_msg_thread(message *msg, void *arg) {
if (msg->ID == MESSAGE_DRAW) { // this message indicates which texture my thread was told to draw
graphics_draw_this_texture(tex_handle[msg->texturehandleindex]); // send back the handle so it knows what to draw
}
}
void cleanup_thread(void *arg) {
graphics_cleanup();
}
I am greatly simplifying the interaction with the graphics system here but you get the point. In this example code tex_handle is an automatic variable, and all its values are lost when init_thread completes, so will not be available when process_msg_thread needs to reference it.
I can fix this by using globals but that means I can't have (for instance) two of these threads simultaneously since they would trample on each other's texture handle list since they use the same one.
I can use thread-local globals but is that a good idea?
I came up with one last idea. I can allocate storage on the heap in my parent thread, and send a pointer to in to the children to mess with. So I can just free it when parent thread leaves away since I intend for it to clean up its children threads before it exits anyway. So, something like this:
void init_thread(void *arg) {
GLuint *tex_handle = (GLuint*)arg; // my storage space passed as arg
graphics_init(tex_handle);
}
void process_msg_thread(message *msg, void *arg) {
GLuint *tex_handle = (GLuint*)arg; // same thing here
if (msg->ID == MESSAGE_DRAW) {
graphics_draw_this_texture(tex_handle[msg->texturehandleindex]);
}
}
int main () {
threadCreator factory;
GLuint *tex_handle = new GLuint[50];
factory.createThread(init_thread, tex_handle, process_msg_thread, tex_handle, cleanup_thread, 0);
// do stuff, wait etc
...
delete[] tex_handle;
}
This looks more or less safe because my values go on the heap, my main thread allocates it then lets children mess with it as they wish. The children can use the storage freely since the pointer was given to all the functions that need access.
So this got me thinking why not just have it be an automatic variable:
int main () {
threadCreator factory;
GLuint tex_handle[50];
factory.createThread(init_thread, &tex_handle, process_msg_thread, &tex_handle, cleanup_thread, 0);
// do stuff, wait etc
...
} // tex_handle automatically cleaned up at this point
This means children thread directly access parent's stack. I wonder if this is kosher.
I found this on the internets: http://software.intel.com/sites/products/documentation/hpc/inspectorxe/en-us/win/ug_docs/olh/common/Problem_Type__Potential_Privacy_Infringement.htm
it seems Intel Inspector XE detects this behavior. So maybe I shouldn't do it? Is it just simply a warning of potential privacy infringement as suggested by the the URL or are there other potential issues that may arise that I am not aware of?
P.S. After thinking through all this I realize that maybe this architecture of splitting a thread into a bunch of functions that get called independently wasn't such a great idea. My intention was to remove the complexity of requiring coding up a message handling loop for each thread that gets spawned. I had anticipated possible problems, and if I had a generalized thread implementation that always checked for messages (like my custom one that specifies the thread is to be terminated) then I could guarantee that some future user could not accidentally forget to check for that condition in each and every message loop of theirs.
The problem with my solution to that is that those individual functions are now separate and cannot communicate with each other. They may do so only via globals and thread local globals. I guess thread local globals may be my best option.
P.P.S. This got me thinking about RAII and how the concept of the thread at least as I have ended up representing it has a certain similarity with that of a resource. Maybe I could build an object that represents a thread more naturally than traditional ways... somehow. I think I will go sleep on it.
Put your thread functions into a class. Then they can communicate using instance variables. This requires your thread factory to be changed, but is the cleanest way to solve your problem.
Your idea of using automatic variables will work too as long as you can guarantee that the function whose stack frame contains the data will never return before your child threads exit. This is not really easy to achieve, even after main() returns child threads can still run.