1

I got a core dump from a multi-threaded process segmentation fault crash. While inspecting the core file using GDB, I found some threads (not all) having such backtrace: 

Thread 4 (LWP 3344):
#0  0x405ced04 in select () from /lib/arm-linux-gnueabi/libc.so.6
#1  0x405cecf8 in select () from /lib/arm-linux-gnueabi/libc.so.6
#2  0x000007d0 in ?? ()
#3  0x000007d0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I check in our source code and found those threads do eventually call select(). I'd like to understand why/how those middle frames are omitted.

Such pattern also occurs to read() call.

Any idea what is going on here? I'm afraid that this indicates something wrong with our coredump configuration, or something. Thank you in advance for the help!!

Edit: Thanks for all responses. I apologize I didn't give enough info. Here are more: The executable is built with compiler -g and without any optimizations, using -O0. We generally only used less than half of our RAM 300-400 MB/1G.
Actually, I also saw this pattern backtrace in different core files (dumped for different faults). What makes this symptom really wired (differ from ordinary stack corrupt) is that more than one threads have such back trace pattern, with frame #0, #1 exactly the same as this one, but #2 #3 addresses may differ from this.

user3908777
  • 11
  • 3
  • 1
    See that question about "corrupt stack"? It seems to me that you have a memory problem, in that you overwrite memory not belonging to you, more specifically on the stack. Are you writing beyond the bounds of an array perhaps? Try running a version with debug information with [Valgrind](http://valgrind.org/). – Some programmer dude Aug 05 '14 at 03:55
  • If it is indeed corrupt stack and you use `gcc` to compile your program consider using the **`-fstack-protector-all`** option: http://stackoverflow.com/questions/1629685/when-and-how-to-use-gccs-stack-protection-feature –  Aug 05 '14 at 05:07

2 Answers2

1

It looks like you might be compiling without debugging enabled.

Make sure you pass in -g when compiling.

Also, as Joachim Pileborg mentioned in his comment, the repeated stack frame implies that you probably corrupted your stack somewhere. That is usually the result of writing past the end of an array, into the stored frame pointer.

merlin2011
  • 71,677
  • 44
  • 195
  • 329
  • Without -g he shouldn't be seeing any bt. – rakib_ Aug 05 '14 at 04:31
  • 1
    @rakib, That is not true. What is true is that the `bt` will not give line numbers. Just try to write a segfaulting program and compile without `-g`, then run it under `gdb` and `bt` after the segfault. – merlin2011 Aug 05 '14 at 04:36
  • Oh, yes. You are right, actually i forgot about the segfault (ie coredump), i was thinking about typical programs. – rakib_ Aug 05 '14 at 04:44
0

If you want to check segmentation faults which are causing due to memory related problem or want to check leak of memory than its better to use Valgrind which gives all information regarding memory leak.

Ritesh Prajapati
  • 953
  • 2
  • 13
  • 22