Crash Dump Analysis Patterns (Part 16b, Linux)
This is a Linux variant of Stack Overflow (user mode) pattern previously described for Mac OS X and Windows platforms:
(gdb) bt
#0 0x00000000004004fb in procF ()
#1 0x000000000040054b in procF ()
#2 0x000000000040054b in procF ()
#3 0x000000000040054b in procF ()
#4 0x000000000040054b in procF ()
#5 0x000000000040054b in procF ()
#6 0x000000000040054b in procF ()
#7 0x000000000040054b in procF ()
#8 0x000000000040054b in procF ()
#9 0x000000000040054b in procF ()
#10 0x000000000040054b in procF ()
#11 0x000000000040054b in procF ()
#12 0x000000000040054b in procF ()
#13 0x000000000040054b in procF ()
#14 0x000000000040054b in procF ()
#15 0x000000000040054b in procF ()
#16 0x000000000040054b in procF ()
[...]
(gdb) bt -10
#15409 0x000000000040054b in procF ()
#15410 0x000000000040054b in procF ()
#15411 0x000000000040054b in procF ()
#15412 0x000000000040055b in procE ()
#15413 0x0000000000400575 in bar_one ()
#15414 0x0000000000400585 in foo_one ()
#15415 0x000000000040059d in thread_one ()
#15416 0x0000000000401690 in start_thread (arg=<optimized out>)
at pthread_create.c:304
#15417 0x0000000000432549 in clone ()
#15418 0x0000000000000000 in ?? ()
In case of a stack overflow the stack pointer is decremented beyond the stack region boundary into an non-accessible region so any stack memory access triggers an access violation:
(gdb) x $rsp
0×7eff46109ec0: 0×0
(gdb) frame 1
#1 0x000000000040054b in procF ()
(gdb) x $rsp
0×7eff4610a0e0: 0×0
(gdb) maintenance info sections
[...]
Core file:
[...]
0×7eff46109000->0×7eff4610a000 at 0×02034000: load13 ALLOC LOAD READONLY HAS_CONTENTS
0×7eff4610a000->0×7eff4690a000 at 0×02035000: load14 ALLOC LOAD HAS_CONTENTS
[…]
- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -