Bug #2282

gdb segfaults with certain corefiles

Added by tuxillo almost 3 years ago. Updated almost 3 years ago.

Status:In ProgressStart date:01/18/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Hi,

In some vkernel cores (not all of them) I get gdb segfaults:

"ps" -- when kernel debugging, type out a ps-like listing of active processes.
Reading symbols from /vkernels/01/vkernel...done.

warning: core file may not match specified executable file.
[New process 1]
[New process 1]
[New process 2]
[New process 3]
[New process 4]
[New process 5]
[New process 6]
[New process 7]
Core was generated by `kernel'.
Program terminated with signal 4, Illegal instruction.
#0 <signal handler called>
(gdb) bt
#0 <signal handler called>
Segmentation fault (core dumped)

GDB backtrace itself is:

"ps" -- when kernel debugging, type out a ps-like listing of active processes.
Reading symbols from /usr/bin/gdb...done.
[New <main task>]
Core was generated by `gdb'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000801503b19 in memalloc (size=144, flags=1) at /home/source/dfbsd/lib/libc/../libc/stdlib/dmalloc.c:723
723 flags |= g_malloc_flags;

#0 0x0000000801503b19 in memalloc (size=144, flags=1) at /home/source/dfbsd/lib/libc/../libc/stdlib/dmalloc.c:723
#1 0x000000080150471c in calloc (number=<optimized out>, size=<optimized out>) at /home/source/dfbsd/lib/libc/../libc/stdlib/dmalloc.c:609
#2 0x0000000000496e5a in xcalloc (number=1, size=144) at /home/source/dfbsd/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb-7/gdb/utils.c:1521
#3 0x0000000000496e8b in xzalloc (size=1) at /home/source/dfbsd/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb-7/gdb/utils.c:1485
#4 0x0000000000407461 in exceptions_state_mc_init (func_uiout=0x4000000b70, exception=0x1, mask=2)
at /home/source/dfbsd/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb-7/gdb/exceptions.c:77
#5 0x0000000000575194 in amd64_sigtramp_frame_cache (this_frame=<optimized out>, this_cache=<optimized out>)
at /home/source/dfbsd/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb-7/gdb/amd64-tdep.c:2097
#6 0x0000000000575674 in amd64_sigtramp_frame_prev_register (this_frame=0x90, this_cache=0x1, regnum=2)
at /home/source/dfbsd/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb-7/gdb/amd64-tdep.c:2149
#7 0x0000000000492b18 in frame_unwind_register_value (frame=0x1000041f0c8, regnum=7) at /home/source/dfbsd/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb-7/gdb/frame.c:953
#8 0x0000000000492db7 in frame_register_unwind (frame=0x90, regnum=1, optimizedp=0x2, unavailablep=0x7fffe0000228, lvalp=0xf0, addrp=0x7fffe0000220, realnump=0x7fffe000021c,
bufferp=0x7fffe0000240 "") at /home/source/dfbsd/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb-7/gdb/frame.c:859
#9 0x0000000000492f8c in frame_unwind_register (frame=0x90, regnum=1, buf=<optimized out>)
at /home/source/dfbsd/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb-7/gdb/frame.c:913
#10 0x0000000000493016 in frame_unwind_register_unsigned (frame=0x1000041f0c8, regnum=7) at /home/source/dfbsd/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb-7/gdb/frame.c:1025

(...)

backtrace repeats itself over and over ...

More information can be provided on demand.

Cheers,
Antonio Huete

History

#1 Updated by tuxillo almost 3 years ago

  • Status changed from New to In Progress

Matt indicates it can be an endless recursion in gdb, as it ran out of stack.

01:24 <@dillon> info regi ... what is %rsp ?
01:25 < tuxillo> rsp 0x7fffdfffff90 0x7fffdfffff90
01:25 <@dillon> stack overflow
01:25 <@dillon> gdb got into an endless recursion probably

Also available in: Atom PDF