Although it mysteriously went away for quite a while (don’t know why), my
game consistently crashes on exit. My error logs show that my four
simulation threads and the two miscellaneous threads all reach their return
statement, but the program execuation does not get past
SDL_WaitThread(insert thread pointer here, NULL); Wondering if my threads
are misbehaving in some way, I commented out all of their actual code except
for while (!quit), where quit is a global bool. To repeat: the crash occurs
even when the threads do absolutely nothing except being trapped in a while
loop until quit is set to true by main. Sometimes the crash is an
unexplained Windows crash, sometimes a Dr. Watson crash saying that it
couldn’t attach to the process. This seems to happen less frequently as I
comment out each thread, with the crashes stopping when only 1 simulation
thread is being executed (and it doesn’t matter which one). Does anybody
have any idea why this might be going on?
~Greg Peele_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
I have a problem using sdl and gl in windows with sdl that it crashes on
exit as well. It crashes even if i have a skeleton program that just inits
and then quits. It even crashes with the example sdl/gl source you can
download from the sdl page. Very odd.> ----- Original Message -----
From: light_gazer@hotmail.com (Gregory Peele)
To:
Sent: Tuesday, August 20, 2002 12:46 PM
Subject: [SDL] Odd threading problems
Although it mysteriously went away for quite a while (don’t know why), my
game consistently crashes on exit. My error logs show that my four
simulation threads and the two miscellaneous threads all reach their
return
statement, but the program execuation does not get past
SDL_WaitThread(insert thread pointer here, NULL); Wondering if my
threads
are misbehaving in some way, I commented out all of their actual code
except
for while (!quit), where quit is a global bool. To repeat: the crash
occurs
even when the threads do absolutely nothing except being trapped in a
while
loop until quit is set to true by main. Sometimes the crash is an
unexplained Windows crash, sometimes a Dr. Watson crash saying that it
couldn’t attach to the process. This seems to happen less frequently as I
comment out each thread, with the crashes stopping when only 1 simulation
thread is being executed (and it doesn’t matter which one). Does anybody
have any idea why this might be going on?
El Tue, 20 Aug 2002 15:46:51 -0400
"Gregory Peele" <light_gazer at hotmail.com> escribi?:
Although it mysteriously went away for quite a while (don’t know why), my
game consistently crashes on exit. My error logs show that my four
simulation threads and the two miscellaneous threads all reach their return
statement, but the program execuation does not get past
SDL_WaitThread(insert thread pointer here, NULL); Wondering if my threads
are misbehaving in some way, I commented out all of their actual code except
for while (!quit), where quit is a global bool. To repeat: the crash occurs
even when the threads do absolutely nothing except being trapped in a while
loop until quit is set to true by main. Sometimes the crash is an
unexplained Windows crash, sometimes a Dr. Watson crash saying that it
couldn’t attach to the process. This seems to happen less frequently as I
comment out each thread, with the crashes stopping when only 1 simulation
thread is being executed (and it doesn’t matter which one). Does anybody
have any idea why this might be going on?
Altought I can’t figure correctly out what’s going your code to crash, there
are some caveats you may find interesting:
If you’re depending upon the state of a global variable, you better declare
that variable ‘volatile’, or your compiler might assume the wrong thing while
optimizing.
Once a thread is finished, its thread pointer is no longer valid, thus using
it will probably generate a crash. If you need to check a thread is finished,
a good way might be to have a global status variable changed at the very end of
the thread main function.
Maybe your shutdown code looks somewhat like this:
This way, it could happen that the thread_1 is actually the latter to finish,
then you go waiting for thread_2, that pointer is no longer valid and thus you
get a crash.
This way, it could happen that the thread_1 is actually the latter to finish,
then you go waiting for thread_2, that pointer is no longer valid and thus you
get a crash.
So SDL_WaitThread() is unnecessary for thread cleanup?
More like YOU PROGRAM is responsible for thread cleanup, and calling
SDL_WaitThread() on a thread that already exited may be illegal.
In other words, your program may need to do some thread cleanup to
ensure that it exits in a sane state, and you probably shouldn’t try to
exit the program until your threads have finished, but SDL_WaitThread()
isn’t the way to do that… use a global flag (or array of global flags)
instead. (For the record, packing the flags into a single byte is
probably a bad idea unless you either mutex protect it, or can guarentee
that the bit-sets and bit-clears are atomic operations.)
Hope that helps,
-LorenOn Wed, 2002-08-21 at 10:04, Christopher Subich wrote:
At 01:31 PM 8/21/02 +0200, you wrote:
Maybe your shutdown code looks somewhat like this:
This way, it could happen that the thread_1 is actually the latter to finish,
then you go waiting for thread_2, that pointer is no longer valid and thus you
get a crash.
So SDL_WaitThread() is unnecessary for thread cleanup?
This way, it could happen that the thread_1 is actually the latter to
finish, then you go waiting for thread_2, that pointer is no longer valid
and thus you get a crash.
So SDL_WaitThread() is unnecessary for thread cleanup?
Not really. System cleanup is performed automagically when the main routine of
the thread exits.
WaitThread is intended for YOU to do some additional cleanup that needs to be
done once the thread is finished. Closing system semaphores is a good example
of that (i.e.: you might want to be sure the other thread is not waiting for a
semaphore you’re going to destroy).