This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

How does "bt" determine where to stop? (C++ and exceptions)

In the info docs, it says that "bt" will backtrace until main.  I've got a
problem in my program where it uses too much stack space.  Unfortunately, "bt"
isn't helping because it won't backtrace beyond "throw_helper"--I'm pretty
sure my program was throwing an exception, but I can't tell because I can't
get more than this:

(gdb) bt
#0  0x4029076e in pthread_handle_sigrestart (sig=32, ctx={gs = 0, __gsh = 0,
      fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0,
      edi = 3202285892, esi = 1078558464, ebp = 3202285828, esp = 3202285800,
      ebx = 3202285892, edx = 3202350760, ecx = 8, eax = 4294967292,
      trapno = 16, err = 0, eip = 1077747214, cs = 35, __csh = 0,
      eflags = 646, esp_at_signal = 3202285800, ss = 43, __ssh = 0,
      fpstate = 0x0, oldmask = 2147483648, cr2 = 0}) at pthread.c:680
#1  <signal handler called>
#2  0x403d1e0e in __sigsuspend (set=0xbedf0144)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
#3  0x40291d14 in __pthread_lock (lock=0x40493934, self=0xbedffe60)
    at restart.h:32
#4  0x4028f13b in __pthread_mutex_lock (mutex=0x40493924) at mutex.c:84
#5  0x4048368f in find_fde (pc=0x80abad8) at ../../gcc/frame.c:626
#6  0x4034660b in throw_helper (eh=0x80a6f00, pc=0x402888c0,
    my_udata=0x401845e8, offset_p=0x401794c7)
   from /usr/local/libstdc++/lib/

In my program I've set ulimit -s 64 to try to track down another problem, but
the problem I get into every time I try to debug a program with exceptions in
it is that GDB craps out when one tries to use "bt".  It seems like exception
handling can confuse the debugger pretty good.

Do you folks run into this problem, or do you have a patch for it, or am I
just nuts?  This sort of thing is a real killer.  Every time I have a section
in my C++ program that throws an exception that isn't caught properly, I get
the same thing, and it costs several hours of tracking down, as the debugger
is useless at that point.  I've tried setting a breakpoint at
__unwinding_cleanup() as was mentioned on the list a while ago, but this no
longer works.

I'm running GDB 5.0, w/glibc 2.1.2 and gcc 2.95.2 on i686 Linux Mandrake, if
that helps, but GDB 4.17 does the same thing.

I'm looking at the source for GDB 5.0 now, and I'll keep trying, but I would
really appreciate some enlightenment in this area.
George T. Talbot
<george at moberg dot com>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]