Date: Fri, 11 Oct 2002 09:57:43 +0200 From: Joerg Barfurth <joerg.barfurth@sun.com> To: kevin.hendricks@sympatico.ca Cc: Martin Blapp <mb@imp.ch>, Alexander Kabaev <ak03@gte.com>, openoffice@FreeBSD.ORG, kan@FreeBSD.ORG Subject: Re: [porting-dev] FreeBSD: Uncatched exception problem Message-ID: <3DA68477.8010005@sun.com> References: <20021011004639.F15308-100000@levais.imp.ch> <openoffice.porting.dev-200210102031.00496.kevin.hendricks@sympatico.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Kevin, all,
Kevin B. Hendricks wrote:
> Hi,
>
> One other thing, if it is over the component interface (possibly the bridge
> itself) then the shared libs would be dlopened and not directly linked.
>
> I am not sure if that is an importnat distinction but we could modify the
> test case to dlopen the libraries instead of linking directly to them.
>
> Again, this is just a wag.
>
> I would guess the best way to examine this issue to to create a debug
> version of the stack walkback code having it print out everyting it does
> during the walkback to see if something screams at us.
>
> Not being able to recreate it on my machine certainly makes debugging it a
> real guessing game.
I'll try guessing along.
Looking at an earlier message in this thread, the title of this thread
is wrong:
Martin Blapp wrote:
> I'm again trying to solve this. A thing I do not understan is, that frame 4
> shows __cxa_rethrow, but in single stepping I never hit it, and also the
> breakpoint I hit was not this one.
>
> Does this bring more light into this difficult bug ?
>
> #0 0x28c30d5b in kill () from /usr/lib/libc.so.5
> #1 0x28c8fa44 in abort () from /usr/lib/libc.so.5
> #2 0x28ba8c8f in __cxxabiv1::__terminate(void (*)()) (handler=0x28c8f9d8 <abort>)
> at /usr/src/contrib/libstdc++/libsupc++/eh_terminate.cc:47
> #3 0x28ba8cd0 in __cxxabiv1::__unexpected(void (*)()) (handler=0x8125e30)
> at /usr/src/contrib/libstdc++/libsupc++/eh_terminate.cc:57
> #4 0x28ba8c04 in __cxa_rethrow () at /usr/src/contrib/libstdc++/libsupc++/eh_throw.cc:77
> #5 0x2aa36ac7 in SfxFrameLoader::detect(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&) () from /usr/local/OpenOffice.org1.0/program//libsfx641fi.so
>
> Then I set a break for __cxa_rethrow and __cxa_throw.
>
> Breakpoint 1, __cxa_throw (obj=0x8128250, tinfo=0x2ab68dec,
> dest=0x2aa38f2c <com::sun::star::lang::WrappedTargetRuntimeException::~WrappedTargetRuntimeException()>) at /usr/src/contrib/libstdc++/libsupc++/eh_throw.cc:58
> 58 __cxa_exception *header = __get_exception_header_from_obj (obj);
Look at frame #3: This is not an uncaught exception, but an *unexpected*
exception. The runtime code believes it has seen an exception spec
violation.
From the preceding mail I gather that we are throwing a
WrappedTargetRuntimeException. This exception is derived as follows
(omitting the "com::sun::star" namespace they are all in):
lang::WrappedTargetRuntimeException
-> uno::RuntimeException
-> uno::Exception
Note that none of these exception classes is polymorphic (has any
virtual function), so they also don't have virtual tables. They don't
even have virtual destructors. Furthermore their only member functions
are all inline: They have inline constructors and implicit,
compiler-generated (but nontrivial) destructors.
I suppose a WrappedTarget*Runtime*Exception (in itself an ugly hack) is
used because we are crossing some interface that only allows
RuntimeException (all uno interface functions do).
That the exceptions are non-polymorphic and inline (like all UNO
exception classes) may have implications on the kind and location of
type info generated for the exceptions and whether the runtime is able
to match them between libraries and down an inheritance hierarchy.
So the scenario you need to test needs two non-polymorphic, completely
inline classes, one derived from the other. Then the derived class is
thrown across shared lib boundaries and some function between the throw
and its catch does only allow the base class in its exception spec.
Without seeing more debugger info I'm not sure what stack frame causes
the 'unexpected' - might this be yet in another shared object ? If you
can't find out in the debugger, you might add
try
{
do_the_call_that_throws();
}
catch (...)
{
fprintf(stderr,"Here !");
throw
}
blocks at intermediate stack levels to see how far you get.
Not much more I can do without an actual debugger in front of me, sorry.
HTH, Jörg
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-openoffice" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DA68477.8010005>