This is the mail archive of the gdb@sourceware.cygnus.com 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]

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


I didn't realize that the current method for exception handling does setjmp()
and longjmp().

Unfortunately, whatever it uses, the approach you suggest only works in a
program which throws exceptions very infrequently.  If I have a program that
uses exceptions frequently, this approach isn't going to work.  Also, in the
backtrace I showed you, I know that there are a zillion frames below that
throw_helper, so I know it isn't the top of the stack.  Is there anything that
could be done to the debugger to help it to recognize the situation?

--
George T. Talbot
<george at moberg dot com>


Daniel Berlin wrote:
> 
> 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>
> >

--
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]