gcc-2.95.3: EH and shared libs

[Kurt Garloff <kurt at garloff dot de>]

Hi,

are there any known problems with gcc-2.95.3, C++ exception handling and
shared libraries? We see the following on a ix86-suse-linux-gnu system:
[...]
#3  0x40f88edb in abort () from /lib/libc.so.6
#4  0x400391eb in __default_terminate () from plugins/.libs/libmcplugins.so.0
#5  0x4003920c in __terminate () from plugins/.libs/libmcplugins.so.0
#6  0x40039c84 in throw_helper (eh=0x80ef0b8, pc=0x40ef95b6, 
    my_udata=0xbfffdb54, offset_p=0xbfffdb50)
    from plugins/.libs/libmcplugins.so.0
#7  0x40039e3c in __throw () from plugins/.libs/libmcplugins.so.0
#8  0x40200305 in plLeafItem::operator unsigned int (this=0x80cb9f0)
    at /home/garloff/Physics/gum/linux-dbg/../plparser/leaf.h:57
#9  0x40ef95b7 in mdStoichiometry::Parse (this=0x81301d4, active=0x80cb9f0, 
    end=0x80cb9fc) at ../../../Fluid/src/mdstoich.cpp:31
[...]

This means that the exception was not caught, despite a handler being
present. IOW, throw_helper() did not find any handler, though it should
have been possible to find ...
(New call trace, with breakpoint at 0x40db4035 check_syntax() to get the
full trace) 

#0  check_syntax (bptr=0x80d10c8 "e", eptr=0x80d10c8 "e")
    at /home/garloff/Physics/gum/linux-dbg/../plparser/lib/../src/strtox.cpp:89
#1  0x40e09230 in void safe_strtoX<unsigned int> (result=@0xbfffdbb0, 
    value=@0x80cb9f0, unit=@0xbfffdbe0)
    at /home/garloff/Physics/gum/linux-dbg/../plparser/lib/../src/strtox.cpp:139
#2  0x40e092d9 in unsigned int strToX<unsigned int> (arg=@0x80cb9f0, 
    unit=@0xbfffdbe0)
    at /home/garloff/Physics/gum/linux-dbg/../plparser/lib/../src/strtox.cpp:197
#3  0x402002df in plLeafItem::operator unsigned int (this=0x80cb9f0)
    at /home/garloff/Physics/gum/linux-dbg/../plparser/leaf.h:57
#4  0x40ef95b7 in mdStoichiometry::Parse (this=0x812e4bc, active=0x80cb9f0, 
    end=0x80cb9fc) at ../../../Fluid/src/mdstoich.cpp:31

The code that throws look like this:
87      void check_syntax( const char *bptr, char *eptr)
88      {
89              if (bptr == eptr)
90                      throw plParserException("Bogus number found.");

It's caught at frame 2 and rethrown:

(gdb) l 198
193     T strToX( const std::string &arg, const std::string & unit)
194     {
195             T result;
196             try {
197                     safe_strtoX<T>( result, arg, unit);
198             }
199             catch ( plParserException & exc)
200             {
201                     throw plParserException( "error while parsing \"" 
202                         + arg + "\" (in units of \"" + unit +"\")", &exc);

This exception is (re)thrown successfully (as we can see from cerr added to
the plParserException c'tor).

The (failing) try catch block finally is in frame 4:
(gdb) f 4
#4  0x40ef95b7 in mdStoichiometry::Parse (this=0x812e4bc, active=0x80cb9f0, 
    end=0x80cb9fc) at ../../../Fluid/src/mdstoich.cpp:31
(gdb) l
[...]
29                      unsigned N = 1;
30                      try {
31                              N = *active;
32                              ++active;
33                      }
34                      catch (plParserException& /* unused exc */)
35                      {

I wonder whether the unwind has worked correctly: I would not expect to see
frame 8 (resp. 3) in the uppermost (resp. new) backtrace anymore.

The code has been called from a wxGTK (2.2.9) event handler:

#12 0x402786c3 in plWXModelViewer::OnInstall (this=0x80d3e40)
    at /home/garloff/Physics/gum/linux-dbg/../plgeneric/lib/wx/../../src/wx/wxmodelbaseviewer.cpp:532
#13 0x4065fa72 in wxEvtHandler::SearchEventTable ()
    from /usr/X11R6/lib/libwx_gtk-2.2.so.6

Some notes on the application:
* It's linked against a variety of shared libraries (44 shlibs)
* The throw and the rethrow come from
  0x40d99310  0x40e1f0b4  Yes
        /home/garloff/Physics/gum/linux-dbg/plparser/lib/.libs/libparser.so.0
  whereas the try catch is in 
  0x40ef9300  0x40f03994  Yes         lib/.libs/libfluid.so.0
  But it is allowed to catch exceptions from another shared lib, AFAICS.
* The exception c'tor is implemented in a header file (in class def. 
  -> static inline).
* All code has been compiled with -fPIC -DPIC
* No code has been compiled with -fomit-frame-pointer
  (that breaks exception handling right away, even though that does not
   seem to be documented)
* We do not use throw() or throw(plParserException) declarations.
* The code supports loading plugins with libdl, but the above has been
  produced by the core code (no libdl loaded code involved)
* wxGTK-2.2.9 compile flags were


There are a couple of things which makes me wonder whether we trigger a
strange compiler bug or do something completely illegal which just
accidently works most of the time.

* If we compile a console version of the program which does not use wxGTK,
  the exception is caught as it should. Code path to the exception is
  the same, except that it's called on behalf of main() without wxGTK
  event handlers in between.
* Before this unhandled exception occurs, a couple of other exceptions 
  has already been thrown and caught successfully. Those exceptions
  are of the same type plParserException, but thrown and caught from 
  different places than the unhandled one
* If we compile the code (i.e. all C++ libs) with gcc-3.1, we did not
  (yet?) see any such problem
* We had a similar problem in another application that uses the parser
  when we linked against a wxGTK compiled with -mcpu=i686. With -mcpu=i486,
  the bug went away. Weird!
* This strange workaround did not help with the current code.
* The problem does not seem to occur, however, on a different computer,
  where SuSE Linux 7.3 is installed. The one where the problem is seen,
  has SuSE Linux 8.0. Now, one of the differences between those two distros
  is that for SL8.0 -mcpu=i686 has been used by default for compiling
  packages (including 2nd stage compiler compilation). Another difference
  is glibc (ld.so could be involved, no?): SL7.3 has 2.2.4, whereas SL8.0
  has 2.2.5.


We're slowly running out of ideas on how to debug this.
Maybe we're just doing something stupid? Or hitting a known compiler bug?
Maybe somebody has hit a similar problem before?
Any input is welcome!

PS: Please Cc: on reply.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations    <K.Garloff@TUE.NL>     [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

Attachment: msg00394/pgp00000.pgp
Description: PGP signature