程序接收信号SIGSEGV，分段故障（程序耗尽堆栈。）

Question

I get this error message when i run the program with gdb. The error is shown at this line:

long a = thread_fake(); //in file1.c

I was getting the problem with other function that was defined in a separate file, so i simplified it to a simple function that just returns 0. The function has been defined as:

long thread_fake(){ //defined in file2.c
    return 0;
}

As @EmployedRussian pointed out, it seems the program runs out of stack. The valgrind shows the following error:

==14711== 144 bytes in 1 blocks are possibly lost in loss record 17 of 32
==14711==    at 0x4025315: calloc (vg_replace_malloc.c:467)
==14711==    by 0x4010CD7: allocate_dtv (dl-tls.c:300)
==14711==    by 0x401146B: _dl_allocate_tls (dl-tls.c:464)
==14711==    by 0x40475C6: pthread_create@@GLIBC_2.1 (allocatestack.c:570)
==14711==    by 0x8050583: tm_main_startup 
==14711==    by 0x8048F6B: main (genome.c:201)
==14711== 144 bytes in 1 blocks are possibly lost in loss record 18 of 32
==14711==    at 0x4025315: calloc (vg_replace_malloc.c:467)
==14711==    by 0x4010CD7: allocate_dtv (dl-tls.c:300)
==14711==    by 0x401146B: _dl_allocate_tls (dl-tls.c:464)
==14711==    by 0x40475C6: pthread_create@@GLIBC_2.1 (allocatestack.c:570)
==14711==    by 0x804DFE3: thread_startup (thread.c:151)
==14711==    by 0x8048F73: main (genome.c:203)

All the threads created are joined a corresponding pthread_join call. Also i tried the sgcheck tool but it doesn't work on the platform'x86-linux'. Please help.

The complete output of bt command:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x406e8b70 (LWP 19416)]
sequencer_run (argPtr=0x89fce00) at sequencer.c:251
251 a = thread_fake();
(gdb) bt
#0  sequencer_run (argPtr=0x89fce00) at sequencer.c:251
#1  0x0804e306 in threadWait (argPtr=0x89dc1f4) at ../lib/thread.c:105
#2  0x4003be99 in start_thread (arg=0x406e8b70) at pthread_create.c:304
#3  0x40253cbe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Answer 1

The error is shown at this line:

long a = thread_fake(); //in file1.c

The likely way this could case a SIGSEGV is if your program has run out of stack.

Examine actual crashing instruction in GDB with x/i $pc .

If the instruction is a PUSH , or a CALL , then my guess is confirmed.

Another possibility: you've compiled your code with optimization, and the actual faulting instruction has little to do with the source line it is attributed to.

Update:

Yes it gives a call call 0x804e580 <thread_fake> . What could be the solution?

The solution is to not run out of stack. Execute a GDB where command, then, in each frame leading to the crash, execute info frame and look for frames that are excessively large.

Don't allocate too much data on stack, or increase your stack size ( ulimit -s ).

valgrind shows the following error:

That is

• not an error
• has nothing to do with your problem

Update2:

How do I check the size of each frame?

Given this:

Stack level 0, frame at 0xffffc248:
...
Stack level 1, frame at 0xffffc250:
...
Stack level 2, frame at 0xffffc2a0:

the size of frame #1 is 8 ( 0xffffc250 - 0xffffc248 ), frame #2 is 80 , etc.

Final Update:

It turned out that my procedure above failed to measure the size of frame#0, which turned out to be ... 61MB! due to presence of humongous local arrays (just as Grady Player correctly guessed).