libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [libunwind] indirect calling libunwind by using exception han dling?


From: Mensing, Joerg
Subject: RE: [libunwind] indirect calling libunwind by using exception han dling?
Date: Mon, 19 Apr 2004 20:42:25 +0200

Hi David,

> From: address@hidden
> Sent: Montag, 19. April 2004 20:13
> To: Mensing, Joerg
> Cc: Hyland, Patrick; Bruggeman, Otto; Sinnwell, Markus;
> 'address@hidden'
> Subject: Re: [libunwind] indirect calling libunwind by using exception 
> handling?
> 
> >>>>> On Mon, 19 Apr 2004 12:16:08 +0200, "Mensing, Joerg" 
> <address@hidden> said:
> 
>   Joerg> Hi, does linking with 'libunwind 0.96' directly influences
>   Joerg> gcc's own exception handling behaviour?
> 
> It does implement the C++ ABI-defined exception support routines (the
> functions starting with names _Unwind_*).  Those routines are also
> implemented in libgcc_s.so.
> 
>   Joerg> Is i.e. any C++ runtime library function overloaded?
> 
> ...
> 
>   Joerg> I would like to use 'libunwind 0.96' for stack backtrace
>   Joerg> only.
> 
> For what reason?  The unwinder implemented by gcc is known to be buggy
> and minimally maintained.
> 
>   Joerg> It seems to work fine, but we are running into a problem
> 
> I would like to use 'libunwind 0.96' for stack backtrace 
> only. It seems to work fine, but we are running into a problem
> 
>   Joerg> > (gdb) where
>   Joerg> > #0  0x20000000001b46c0 in 
> parse_lsda_header(_Unwind_Context*,
>   Joerg> > unsigned char const*, lsda_header_info*) ()
>   Joerg> >    from /usr/lib/libstdc++.so.5
>   Joerg> > #1  0x20000000001b4d60 in __gxx_personality_v0 () from
>   Joerg> > /usr/lib/libstdc++.so.5
>   Joerg> > #2  0x40000000015b6f40 in _Unwind_Phase2
>   Joerg> > (exception_object=0x60000000002573a0, 
> context=0x20009719860)
>   Joerg> > at unwind-internal.h:61
>   Joerg> > #3  0x40000000015b6d70 in _Unwind_Resume
>   Joerg> > (exception_object=0x60000000002573a0) at 
> _Unwind_Resume.c:37
>   Joerg> > #4  0x2000000002234160 in
>   Joerg> > Cconsistent::DROP_CURRENT_SCHEMA(char (*) [64])
>   Joerg> > (this=0x60000000002573a0, SchemaName=0x2000b5e8899)
>   Joerg> >     at consistentObj.cpp:2674
> 
>   Joerg> when Cconsistent::DROP_CURRENT_SCHEMA() throw an
>   Joerg> exception. The problem is still under investigation...
> 
> Sorry, I don't see what the problem is here.  _Unwind_Resume() will
> come from libunwind.so.  That should be fine as long as all
> _Unwind_*() routines come from that library.
> 
> ....

What makes it a problem is the 'Segmentation fault. Signal 11 core dumped...'

Aahhh! The reason may be, that the buggy and minimal maintained unwinder 
implemented 
by gcc was used inside a dynamically loaded DLL! This DLL contains the 
Cconsistent::DROP_CURRENT_SCHEMA()
calls and so the 'throw' statements producing the segmentation fault. I hope 
your last sentence is the clue 
to the problem! The MaxDB/liveCache database kernel dynamically loads triggers 
and object extensions on demand. 
The MaxDB/liveCache database kernel itself is linked with libunwind-0.96 
already! I informed the writers of the DLL to link with your libunwind-0.96 
too! As soon as they report the outcome, i send you another mail.

Thank you again for your fast response
CU
jrg


reply via email to

[Prev in Thread] Current Thread [Next in Thread]