c++/3244: Exception handling fails in 2.95.2 and 2.95.3 in various ways

[coderman@mindspring.com]

>Number:         3244
>Category:       c++
>Synopsis:       Exception handling fails in 2.95.2 and 2.95.3 in various ways
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 18 21:26:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     coderman@mindspring.com - Martin Peck
>Release:        g++ 2.95.2 and 2.95.3
>Organization:
>Environment:
Various Linux environments using various stdc++ libraries associated with the 2.95.2 and 2.95.3 releases.  This is the intel platform.
>Description:
When building a large application using many shared libraries and many classes I encounter problem with exception handling.

In 2.95.2 the application Aborts, behaving as if an exception was raised that did not match the specification of the method that raised it.  In this case the method had no specification at all, which means it should allow any exception to be raised.  When I added a specification for this method, the problem went away.

Using 2.95.3 the application enters the method that raises the exception.  When the exception is raised, the thread spins to 100% CPU and never returns.  Even modifying the exception specification had no effect.

I rebuilt the application using 2.95.3 and used ALL static libraries, making a single stand alone binary (no shared libs like prior attempts).  In this case the application seg faulted once the exception was raised.

Tracing the result in GDB I found that the application was using an exception specification for a COMPLETELY DIFFERENT METHOD! in an entirely separate library.  Some how the exception specification lookup had failed, and the wrong specification was used.  This caused a seg fault.

I am guessing that there is some kind of hash lookup based on fully qualified method name to locate exception specifications.  It appears that perhaps this lookup is not handling collision correctly, and the wrong specification may be used under the right (very improbable) situations.

I have never been able to repeat this error without bulding the entire application.  All subsets fail to show this behavior.  Again, I am assuming that this is due to some kind of symbol collision, which only manifests itself in large applications with lots of shared libraries and classes.
>How-To-Repeat:
unknown.
>Fix:
unknown.
>Release-Note:
>Audit-Trail:
>Unformatted: