I’ve done some more thorough testing, and found out which specific line
in the thread function causes the "threads crash program on return"
problem. It seems to be where I declare a static array of objects I use
for the game. If I comment that part out, everything runs quite
happily, otherwise my program will crash on thread exit, but only if two
or more threads are running ThreadTesting_Pattern (*data is different
for each thread).
int ThreadTesting_Pattern(void *data)
{
// some stuff
Tile tilePattern[108]; // crashes program if I have two threads
// rest of the function
return 0;
}
where Tile is a fairly small object (one Uint16, one Uint8, nothing
dynamic).
I can move this part elsewhere (actually, this kind of initialization
work really belongs in my main thread anyways), but I’m just
curious if there’s any particular reason why this would only crash if
two or more threads are called with this function. If only one
thread is created, everything runs fine. (these threads don’t modify
any non-local variables, so as far as I know, no need to worry about
locking or anything. Unless I’m mistaken about that 
)
Thanks,
Greg Peele
I’ve done some more thorough testing, and found out which specific line
in the thread function causes the “threads crash program on return”
It seems to be where I declare a static array of objects I use
for the game.
int ThreadTesting_Pattern(void *data)
{
// some stuff
Tile tilePattern[108]; // crashes program if I have two threads
// rest of the function
return 0;
}
Why do you say it’s static? The code you showed doesn’t use a static
array, it’s an automatic array, ie. a standard local variable which gets
allocated each time that function is called and deallocated each time
that function exits. If somehow you are passing the address of that
array around between threads, expect chaos when a thread tries to read
memory that another thread just deallocated.From: vector@lightgazer.net (vector at lightgazer.net)
To:
Sent: Tuesday, August 06, 2002 1:54 AM
Subject: [SDL] Re: odd threading issues…
–
Kylotan
At 02:07 AM 8/6/02 +0100, you wrote:
I’ve done some more thorough testing, and found out which specific line
in the thread function causes the “threads crash program on return”
It seems to be where I declare a static array of objects I use
for the game.
int ThreadTesting_Pattern(void *data)
{
// some stuff
Tile tilePattern[108]; // crashes program if I have two threads
// rest of the function
return 0;
}
Why do you say it’s static? The code you showed doesn’t use a static
array, it’s an automatic array, ie. a standard local variable which gets
allocated each time that function is called and deallocated each time
that function exits. If somehow you are passing the address of that
array around between threads, expect chaos when a thread tries to read
memory that another thread just deallocated.
He means static as opposed to heap dynamic. You’re right in that it’s a
stack dynamic array – static is used in the sense of constant size
here. The address of the array is not, to the best of my knowledge, passed
between threads – I’ve talked with him about the project, and IIRC the
array is entirely local to that thread.
El Mon, 5 Aug 2002 20:54:05 -0400
vector at lightgazer.net escribi?:
I’ve done some more thorough testing, and found out which specific line
in the thread function causes the "threads crash program on return"
problem. It seems to be where I declare a static array of objects I use
for the game. If I comment that part out, everything runs quite
happily, otherwise my program will crash on thread exit, but only if two
or more threads are running ThreadTesting_Pattern (*data is different
for each thread).
int ThreadTesting_Pattern(void *data)
{
// some stuff
Tile tilePattern[108]; // crashes program if I have two threads
// rest of the function
return 0;
}
This array is entirely allocated in thread’s stack. Since each thread has its
own stack, be careful not to use the array outside his creator. Also, keep in
mind that some RTL can be in trouble when allocating more than one stack page
(4k) at a time for a thread.
Regards,
Wizord.