From owner-freebsd-openoffice Fri Oct 11 0:57:51 2002 Delivered-To: freebsd-openoffice@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CA8137B401; Fri, 11 Oct 2002 00:57:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FC1443EBE; Fri, 11 Oct 2002 00:57:48 -0700 (PDT) (envelope-from joerg.barfurth@sun.com) Received: from hamburg-mail1.germany.sun.com ([129.157.136.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26578; Fri, 11 Oct 2002 00:57:46 -0700 (PDT) Received: from sun.com (sr-eham02-01 [129.157.136.30]) by hamburg-mail1.germany.sun.com (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id g9B7viR26908; Fri, 11 Oct 2002 09:57:44 +0200 (MEST) Message-ID: <3DA68477.8010005@sun.com> Date: Fri, 11 Oct 2002 09:57:43 +0200 From: Joerg Barfurth User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.0) Gecko/20020611 X-Accept-Language: de-de, de, en-us, en, fr, ru MIME-Version: 1.0 Newsgroups: openoffice.porting.dev To: kevin.hendricks@sympatico.ca Cc: Martin Blapp , Alexander Kabaev , openoffice@FreeBSD.ORG, kan@FreeBSD.ORG Subject: Re: [porting-dev] FreeBSD: Uncatched exception problem References: <20021011004639.F15308-100000@levais.imp.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-freebsd-openoffice@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 ) > 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&) () 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 ) 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