Previous bug reports have identified that exceptions thrown across shared object boundaries are lost. This test case demonstrates the error for exceptions thrown across static library boundaries. Release: gcc-3.2 Environment: alphaev67-dec-osf5.1 How-To-Repeat: * Compile ns1_exceptionBug.cc and add to libA.a * Compile ns2_exceptionBug.cc and add to libB.a * Compile demoExceptionBug.cc, link with libA.a and libB.a * Execute the resulting a.out (Sorry if there are syntax errors in the attached source. I had to retype it on my PC to send this report.)
State-Changed-From-To: open->feedback State-Changed-Why: Unfortunately, the attachment got lost. Can you resend it so that I can append it to the bug report? Thanks Wolfgang
From: "Dan Ingold" <dan@objective-design.com> To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, gnu@ingold.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Subject: Re: c++/8966: Lost exceptions across library boundaries Date: Mon, 16 Dec 2002 16:42:40 -0800 Wolfgang, In retesting, I found that my simplified example does not exhibit the error. My full application does, but it's too complex to submit for a bug report. Will you please delete my bug report for now, and I'll resubmit when I have a better example? Thank you, Wolfgang. Regards, Dan On 17 Dec 2002 00:28:15 -0000 bangerth@dealii.org wrote: >Synopsis: Lost exceptions across library boundaries > >State-Changed-From-To: open->feedback >State-Changed-By: bangerth >State-Changed-When: Mon Dec 16 16:28:13 2002 >State-Changed-Why: > Unfortunately, the attachment got lost. Can you >resend it > so that I can append it to the bug report? > > Thanks > Wolfgang > >http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8966
State-Changed-From-To: feedback->closed State-Changed-Why: Closed upon request of submitter. Thanks for your quick feedback, BTW. W.
State-Changed-From-To: closed->suspended State-Changed-Why: Based on Gaby's comments, I put this into suspended state. His comments were misfiled, so here they are: Le Mardi 17 D=E9cembre 2002 11:07, vous avez =E9crit : > "Dan Ingold" <dan@objective-design.com> writes: > | Wolfgang, > | > | In retesting, I found that my simplified example does not exhibit the > | error. My full application does, but it's too complex to submit for a > | bug report. > > I would like to add some note to this report. > > You're not the first person I'm seeing mentionning this behaviour. > Last month, I discussed a similar issue with Christophe de Vienne > (cdevienne@alphacent.com) on the French speaking newsgroup > news:fr.comp.lang.c++. See thread starting at > > Message-ID: <argfeo$8iq$1@news-reader10.wanadoo.fr> > > if you can read French. Typically, some exceptions thrown from a shared > library lib1 could not be caught in another shared library lib2. He > spent lots of days trying to reduce the problem to a smaller testcase, > but didn't succeed :-( This issue is reported as a regression from 2.95.x Hi, I'm almost glad to see I'm not the only one who had this problem ;-) Just a precision : I tried to use some static library instead with the hope= it=20 would correct the problem. It did not :-( So this does not comes from the shared libs. And it seemed to me that the problem came when there is more than 2 libs si= nce=20 I couldn't reproduce it smaller, even with 3 libs if I remember well. Hope this will somehow help, Christophe
The almost sounds like the typeinfo is not the same in both shared libraries when they are loaded which is needed for exceptions to work.
Does OSF support weak symbols and dwarf-2 exceptions.
I'm seeing some similar problems with gcc-3.4 and gcc-3.3.3 on i386-Linux. I've got a routine throwing exceptions. In a simple testcase they get caught fine, but in my program with the same code the exception just falls through and causes a core dump. It's very hard to make a compilable testcase, but I've seen it in two independent bits of code.
It seems that this bug still applies as of g++-4.3, at least with optimizations turned on. We're seeing this as we run the test suite of PPL (see, e.g., https://buildd.debian.org/fetch.cgi?pkg=ppl&arch=alpha&ver=0.10-4&stamp=1235334555&file=log&as=raw). The code even has catch (...), but exceptions still propagate to the top. Reproducible at any time, but I'm afraid we don't have small examples here either. Best, Michael
Perhaps the PPL instance of this problem will be fixed with the switch to strcmp for typeinfo comparison in 4.5.
I have tried to reproduce the problem with g++ 4.5 and couldn't make it fail anymore. The problem, however, is that I couldn't make it fail with g++ 4.4 either. Whatever the essential change might have been, the PPL instance of this problem seems to be fixed. Best, Michael
At this point, I think we can safely close this as fixed in 4.5.