throwing an exception makes gcc to terminate. (gcc Bug?)

throwing an exception makes gcc to terminate. (gcc Bug?)

[Fernando Jeronymo]

Hi. As you can see, I still haven't solved my problem with throwing
exceptions. I can't spare my code with you guys, but I can try to
illustrate what I have (more or less).

first, my specifications:

Compaq machine: Linux tst01 2.4.18-5smp #1 SMP Mon Jun 10 15:19:40 EDT 2002
i686 unknown

gcc:
     Reading specs from
/data/dbk/tools/gcc/3.0.4-Linux/lib/gcc-lib/i686-pc-linux-gnu/3.0.4/specs
     Configured with: ./configure --prefix=/data/dbk/tools/gcc/3.0.4-Linux
--disable-threads
     Thread model: single
     gcc version 3.0.4

I tried to do the same thing with gcc:
     Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.0.4/specs
     Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --host=i386-redhat-linux --with-system-zlib
     Thread model: posix
     gcc version 3.0.4 (Red Hat Linux 7.2 3.0.4-1

Both of them show the same behavior. Exactly the same. The second gcc I got
from a rpm from Red-Hat. The first one I build it myself yesterday without
threads just to be sure.

The machine where I compile and link the application is a Compaq Red Hat
Linux 7.1, and the one where I execute it is a Compaq Red Hat Linux 7.3
(5Gb memory)


Now to the problem:

     class A
     {
          virtual void a();
     }
     void A::a()
     {
          try
          {
               throw 22;
          }
          catch(int& test)
          {
               std::cerr << test << std::endl << std::flush ;
          }
     }


     class B : public A
     {
          void a();
          void c();
     }

     void B::c()
     {
          try
          {
               throw 33;
          }
          catch(int& test)
          {
               std::cerr << test << std::endl << std::flush ;
          }
          A* myA = new A;
          myA->a();
     }


So, this is a very crude example, but my application uses X (And I know for
a fact that the X libraries use setjmp and longjmp). Besides that,
everything else is the same as I have with my other processes that use
exceptions and work just fine. Now, when from B::c() I throw the exception,
everything works just fine and I see a nice 33 coming up in the screen. I
went through the assembly, and the throw 33; line does exactly this:

- throw 33;
     sub  $0xc, %esp
     push $0x4
     call 0x806773c <__cxa_allocate_exception>
     add  $0x10, %esp
     movl $0xa, (%eax)
     sub  $0x4, %esp
     push $0x0
     pushl     0x1488(%ebx)
     push %eax
     call 0x806702c <__cxa_throw>



ok? So, after that, he catches the exception and I see the neat 33 coming
up in the screen. He goes then to myA->a() and inside it I just try to
throw another integer:

- throw 22;
     sub  $0xc, %esp
     push $0x4
     call 0x806773c <__cxa_allocate_exception>
     add  $0x10, %esp
     movl $0x14, (%eax)
     sub  $0x4, %esp
     push $0x0
     pushl     0x1488(%ebx)
     push %eax
     call 0x806702c <__cxa_throw>
     lea  0x0(%si), %si


Now, the fact is that everything is just the same ok? Besides that lea
instruction down there, everything is the same. Nothing else changed and
between method c() and method a() nothing else happens! What goes on is
that <__cxa_throw> fails right on this line on eh_throw.cc:

     // Some sort of unwinding error.  Note that terminate is a handler.
       __cxa_begin_catch (&header->unwindHeader);
       std::terminate ();


And he justs terminates. I have the core down here for you guys, and the
eh_throw.cc part of __cxa_throw. I don't know what else to do anymore. It
doesn't make any sense but being some compiler option, flag, or even a
compiler bug.

So I am completely clueless. I know that if you have a program that is just
like this:

int main()
{
     throw 10;
}

This is going to give almost the same coredump I have. But this is not what
its happening with me.... at some point in the program I can throw just
fine, and just after calling another method and trying to throw from that
second method it coredumps just like if it was the example (main) above....
the only difference is that on the example above we get a raise (signal=6)
and in my problem we have raise ()

Can anyone help me?

Thanks,
Fernando


eh_throw.cc:

extern "C" void
__cxa_throw (void *obj, std::type_info *tinfo, void (*dest) (void *))
{
  __cxa_exception *header = __get_exception_header_from_obj (obj);
  header->exceptionType = tinfo;
  header->exceptionDestructor = dest;
  header->unexpectedHandler = __unexpected_handler;
  header->terminateHandler = __terminate_handler;
  header->unwindHeader.exception_class = __gxx_exception_class;
  header->unwindHeader.exception_cleanup = __gxx_exception_cleanup;

  __cxa_eh_globals *globals = __cxa_get_globals ();
  globals->uncaughtExceptions += 1;

#ifdef _GLIBCPP_SJLJ_EXCEPTIONS
  _Unwind_SjLj_RaiseException (&header->unwindHeader);
#else
  _Unwind_RaiseException (&header->unwindHeader);
#endif

  // Some sort of unwinding error.  Note that terminate is a handler.
  __cxa_begin_catch (&header->unwindHeader);
  std::terminate ();
}



Core:

#0  0x42029241 in kill () from /lib/i686/libc.so.6
#1  0x4202902a in raise () from /lib/i686/libc.so.6
#2  0x4202a7d2 in abort () from /lib/i686/libc.so.6
#3  0x40178405 in __cxxabiv1::__terminate(void (*)()) (handler=0x4202a664
<abort>)
    at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x40178440 in __cxxabiv1::__unexpected(void (*)()) (handler=0x8633500)
    at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x401785b0 in __cxa_rethrow () at
../../../../libstdc++-v3/libsupc++/eh_throw.cc:77
#6  0x082c3de7 in STemplateCtl::postKeystroke(DBKEY) (this=0x86825d0,
key=DBKEY_A) at STemplateCtl.C:693
#7  0x081cac68 in StateControllerGlue::processInput(DBKEY) (this=0x86826c8,
key=DBKEY_A)
    at StateControllerGlue.C:78
#8  0x081b5193 in Control::dispatchFromKeyboard(tagMESSAGE*)
(this=0x85ba5f8, msg=0xbfffcdc4)
    at ControlReceive.C:1285
#9  0x081b260e in Control::dispatch(tagMESSAGE*) (this=0x85ba5f8,
msg=0xbfffcdc4) at ControlReceive.C:289
#10 0x081ddd92 in dispatchThruControl(void*, tagMESSAGE*) (msg=0xbfffcdc4)
at SEventLoop.C:453
#11 0x08327845 in SCallback<void (*)(void*, tagMESSAGE*),
tagMESSAGE*>::operator()(tagMESSAGE*) const (
    this=0x8693858, a1=0xbfffcdc4) at
/mnt/pos.dspb/include/Business/SCallback.h:27
#12 0x08327893 in SCallback<void (*)(void*, tagMESSAGE*),
tagMESSAGE*>::execList(tagMESSAGE*) (this=0x0,
    a1=0xbfffcdc4) at /mnt/pos.dspb/include/Business/SCallback.h:34
#13 0x081ddc9d in SEventLoop::dispatch(tagMESSAGE*) (this=0xbfffcda0,
msg=0xbfffcdc4) at SEventLoop.C:398
#14 0x081ddbba in SEventLoop::loop() (this=0xbfffcda0) at SEventLoop.C:363
#15 0x081ddc28 in SEventLoop::loopUntilMsg(tagMESSAGE*, unsigned short,
SProcedure<bool (*)(void*, tagMESSAGE*), bool, tagMESSAGE*>)
(this=0xbfffcda0, msgAddr=0x0, pq=3681, p={_proc = 0x81dd018 <xfer_never>,
_clientData = 0x0})
    at SEventLoop.C:381
#16 0x081dd263 in SEventLoop::untilMsg(tagMESSAGE*, unsigned short,
SProcedure<bool (*)(void*, tagMESSAGE*), bool, tagMESSAGE*>, bool, bool,
SCallback<void (*)(void*, tagMESSAGE*), tagMESSAGE*>*, SCallback<void
(*)(void*, bool), bool>*) (pMsg=0x0, predQ=3681, p={_proc = 0x81dd018
<xfer_never>, _clientData = 0x0}, unlockKeyboard=false,
    inheritDispatch=false, cbs=0x8693858, lprocs=0x86938f8) at
SEventLoop.C:148
#17 0x081ddf0c in SEventLoop::startTopLevel() () at SEventLoop.C:474
#18 0x08068108 in main (nArgc=5, szArgv=0xbffff0e4) at display.C:68
#19 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6