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

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

[George T. Talbot]

I'm sorry, I thought I mentioned my platform in the previous e-mail.

I'm using i686 Linux Mandrake 7.1.  I'm using the compiler shipped with it
(gcc 2.95.3), glibc 2.1.2 (the one shipped with it won't allow debugging of
shared libraries), and gdb 5.0.

Are you sure that the exception handling mechanism used is
setjmp()/longjmp()?  I thought that that exception model was the old,
non-thread-safe model.  Since I have a heavily multithreaded program, I would
hope I've got the new model, which I understand uses some other thread-safe
throw/catch mechanism.

I'm a little hazy on all this so I may be misunderstanding.

Here's the stack trace again, if it's at all helpful...

(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 = 3212771668, esi = 1078558464, ebp = 3212771604, esp = 3212771576,
      ebx = 3212771668, edx = 3212836520, ecx = 8, eax = 4294967292,
      trapno = 16, err = 0, eip = 1077747214, cs = 35, __csh = 0,
      eflags = 646, esp_at_signal = 3212771576, ss = 43, __ssh = 0,
      fpstate = 0x0, oldmask = 2147483648, cr2 = 0}) at pthread.c:680
#1  <signal handler called>
#2  0x403d1e0e in __sigsuspend (set=0xbf7f0154)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
#3  0x40291d14 in __pthread_lock (lock=0x40493934, self=0xbf7ffe60)
    at restart.h:32
#4  0x4028f13b in __pthread_mutex_lock (mutex=0x40493924) at mutex.c:84
#5  0x4048368f in find_fde (pc=0x808f888) at ../../gcc/frame.c:626
#6  0x4034660b in throw_helper (eh=0x40600550, pc=0x402888c0,
    my_udata=0x401845e8, offset_p=0x401794c7)
   from /usr/local/libstdc++/lib/libstdc++.so.3
(gdb)

One thing that I notice that's weird is that throw_helper, in libgcc2.c in the
compiler sources, does not seem to call find_fde().  I don't know--this is all
getting to be quite confusing.

Were there any ABI changes between 2.95.2 and 2.95.3?

 
P.S.  your reply address in that last mail was:
            Daniel Berlin <"dberlin"@cygnus.com@dan2.cygnus.com>
	which the mail server didn't understand...


Daniel Berlin wrote:
> 
> "George T. Talbot" <george@moberg.com> writes:
> 
> > I didn't realize that the current method for exception handling does setjmp()
> > and longjmp().
> >
> It varies from platform to platform, but the code you show implies that is what your platform is using.
> 
> What platform are you using, anyway?
> > 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?
> >
> 
> Actually, i implemented catch throw, and catch catch on BeOS by doing just this, plus a little extra code to determine why we threw/caught.
> If you tell me what platform/version of gcc you are using, it would help a bunch.
> Their really aren't a zillion frames when you setjmp, the top is the setjmp caller. Until the longjmp, that is really the stack.
> 
> It would take a *lot* of work to make it identify what variable the setjmp was stored into, read the rest of the stack from that variable, and so on.
> The real solution is what was already done, which is use a better exception handling mechanism.
> 
> > --
> > George T. Talbot
> > <george at moberg dot com>
> >

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

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

[Daniel Berlin]

"George T. Talbot" <george@moberg.com> writes:

> I didn't realize that the current method for exception handling does setjmp()
> and longjmp().
> 
It varies from platform to platform, but the code you show implies that is what your platform is using.

What platform are you using, anyway?
> 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?
> 

Actually, i implemented catch throw, and catch catch on BeOS by doing just this, plus a little extra code to determine why we threw/caught.
If you tell me what platform/version of gcc you are using, it would help a bunch.
Their really aren't a zillion frames when you setjmp, the top is the setjmp caller. Until the longjmp, that is really the stack.

It would take a *lot* of work to make it identify what variable the setjmp was stored into, read the rest of the stack from that variable, and so on.
The real solution is what was already done, which is use a better exception handling mechanism.

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

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

[George T. Talbot]

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>

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

[Daniel Berlin]

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

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

[George T. Talbot]

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>