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]

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

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/

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">
	which the mail server didn't understand...

Daniel Berlin wrote:
> "George T. Talbot" <> 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>

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