OK, I'm feeling really dumb right now on a C program I'm working on. I'm getting a segfault that I assume is due to an int array I am creating. I say "i assume" because when I comment out that line of code, the segfaults go away.

The code is multi-threaded using pthreads, and I change the number of threads by a #define directive. A low number of threads never causes the segfault. I am manually assigning the stack size before creating the threads, and I am including the overhead of the array.

I've narrowed down the potential area where it occurs and I've gone through and commented out ALL array indexing operations to get eliminate the possibility of bad indexing. It's to the point where I am literally just indexing through for loops.

here's how I am allocating the thread stack size:

Quote :

" pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_getstacksize (&attr, &s); s = 7 * sizeof(int) + 1 * sizeof(long) + #ifndef SKIPSTEAL sizeof(int[NUM_THREADS - 1]) + #endif sizeof(struct1 *) + sizeof(struct2 *) + 100; if (s < PTHREAD_STACK_MIN) s = PTHREAD_STACK_MIN; pthread_attr_setstacksize (&attr, s); "

all of the threads are successfully created before the segfault, and if I run out of memory, the program catches it and aborts.

there's a printf() statement in the threaded section that, if I turn it on, causes the segfault in that section. If I comment it out, the segfault occurs when the joining the threads back to the main thread.

WTF am I missing here?

4/26/2011 8:52:12 PM

wtf is this braindamage?

1.) what compiler/arch/system?
2.) is c++ an option
2.yes) Boost::Threads
3.) gdb/truss/strace/dtrace....give us something here
4.) Are you using a debug malloc?
5.) never "i assume" when working with threads
6.) check pthread_attr_setguardsize
7.) repeat step 4 until your ears bleed
8.) You're completely ignoring alignment issues here
9.) wtf kind of system are you working on that your stacksize needs to be managed so tightly? Are you really not making ANY calls on your worker threads? I guarantee you that PTHREAD_STACK_MIN wins every time unless you're trying to spawn 1,000 threads.
10.) Not checking the returns of pthread* calls is a surefire way to find yourself in the unemployment line


PS. sizeof( struct1 * ) == sizeof( struct2 * ) == sizeof( int *) == sizeof( int )

4/26/2011 11:11:57 PM

1) virtualbox-ed ubuntu from within Win7, x64, gcc
2) no
3) i've gdb-e-d it, but the results make no sense. sometimes it faults in my code, sometimes it faults in system code. and, even when it faults in my code, it's not always in the same place in my code. sometimes it even faults when I try to join the worker threads back to the main thread
4) the fuck? yeah, I'm a noob. it looks like I'm probably using the regular malloc.
8) alignment issues?
9) yes, I want to be able to spawn a shit ton of threads.
10) i'd normally do that, but I don't expect it to crap out, and this is for a class, so it aint going in to production any time soon. could that really be causing trouble?



finally, I've been able to narrow down the "source" of the segfault, but it makes no fucking sense. i've got an line as follows:
victim = threads[i];

victim is an int, threads is an int[], i is an int.

comment out that line, replace it with this line, and it works fine:
k = threads[i];


victim is used only one more time in the thread (in a stripped down version for finding this damned error), and it is as follows:
if (victim == INT_MIN) { /* foo you done fucked up, yo */ }

that's it. if I use the k method and replace victim with k in the if, I get the segfault. set victim = 0 immediately following the threads[] statement, then set victim to 0, no segfault. grrrrrr

right now, GDB gives the following:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6644b70 (LWP 9067)]
0x0011f07a in ?? () from /lib/ld-linux.so.2

4/27/2011 5:10:31 AM

Well, I changed the fudge factor to include 10KB extra for the stack size, and that seems to have cleared everything up. Yay for messing with stuff that is over my head at this point. Thx for the help, all.

4/27/2011 9:44:16 PM