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

[Daniel Berlin <dan at cgsoftware dot com>]

It's not BT that is the problem here, but the exception handling
mechanism. As far as we can tell, throw_helper really *is* the top of the
stack, because of the exception handling mechanism being used
(setjmp/longjmp). 
 Try breakpointing on _throw_helper or _cp_pop_exception.
Or, at worst, on setjmp.
That will catch it before it setjmp's, and thus, you'll have the right
stack.

On Tue, 27 Jun 2000, George T. Talbot wrote:

> 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/libstdc++.so.3
> (gdb)
> 
> 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>
>