standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1

[Konstantin Belousov]

On Sun, Jan 20, 2013 at 08:08:21PM -0800, Pedro Giffuni wrote:
> 
> 
> 
> 
> ----- Messaggio originale -----
> > Da: Konstantin Belousov 
> > 
> > On Sun, Jan 20, 2013 at 04:52:00PM +0000, Hongli Lai wrote:
> >> 
> >>  >Number:         175453
> >>  >Category:       standards
> >>  >Synopsis:       Catching C++ std::bad_cast doesn't work in FreeBSD 
> > 9.1
> >>  >Confidential:   no
> >>  >Severity:       non-critical
> >>  >Priority:       low
> >>  >Responsible:    freebsd-standards
> >>  >State:          open
> >>  >Quarter:        
> >>  >Keywords:      
> >>  >Date-Required:
> >>  >Class:          sw-bug
> >>  >Submitter-Id:   current-users
> >>  >Arrival-Date:   Sun Jan 20 17:00:00 UTC 2013
> >>  >Closed-Date:
> >>  >Last-Modified:
> >>  >Originator:     Hongli Lai
> >>  >Release:        9.1-RELEASE
> >>  >Organization:
> >>  Phusion
> >>  >Environment:
> >>  FreeBSD freebsd9 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 
> > 09:23:10 UTC 2012    
> >>  root at farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
> >>  >Description:
> >>  C++ code is not able to catch std::bad_cast exceptions, even though it 
> > should. If a dynamic_cast is within a try-catch block, then that block fails to 
> > catch std::bad_cast, and the program crashes with an uncaught exception as a 
> > result.
> >> 
> >>  I've attached a reproducible test case. You can also find it at 
> > http://forums.freebsd.org/showthread.php?p=205804#post205804 and 
> > http://stackoverflow.com/questions/14413703/why-does-catching-stdbad-cast-not-work-on-freebsd-9. 
> > The code is compiled with the following GCC version:
> >> 
> >>  $ gcc -v
> >>  Using built-in specs.
> >>  Target: amd64-undermydesk-freebsd
> >>  Configured with: FreeBSD/amd64 system compiler
> >>  Thread model: posix
> >>  gcc version 4.2.1 20070831 patched [FreeBSD]
> >> 
> >>  FreeBSD 9.1 seems to be the only platform on which this bug appears. The 
> > code works as expected on Linux and OS X. According to a commenter, FreeBSD 9.0 
> > works as expected too. According to another commenter the code fails on FreeBSD 
> > 9.1 with Clang too.
> >>  >How-To-Repeat:
> >>  See attached C++ program.
> >>  >Fix:
> >> 
> >> 
> >>  Patch attached with submission follows:
> >> 
> >>  #include <exception>
> >>  #include <typeinfo>
> >>  #include <stdio.h>
> >> 
> >>  class foo {
> >>  public:
> >>      virtual ~foo() {}
> >>  };
> >> 
> >>  class bar: public foo {
> >>  public:
> >>      int val;
> >>      bar(): val(123) {}
> >>  };
> >> 
> >>  static void
> >>  cast_test(const foo &f) {
> >>      try {
> >>          const bar &b = dynamic_cast<const bar &>(f);
> >>          printf("%d\n", b.val);
> >>      } catch (const std::bad_cast &) {
> >>          printf("bad cast\n");
> >>      }
> >>  }
> >> 
> >>  int main() {
> >>      foo f;
> >>      cast_test(f);
> >>      return 0;
> >>  }
> >> 
> > Confirmed, and it seems that the culprit is libstdc++. At least replacing
> > the system libstdc++.so.6 with the library from the stock build of gcc
> > 4.7.2 (without touching libgcc_s.so.1) makes the catch operator working.
> > 
> 
> Confirmed,
>  
> The problem is actually not in any of the code updates to libstdc++ but
> in the way libstdc++ is configured/build since 9.0.
> 
> Reverting the changes in stable/9/gnu/lib/libstdc up to r229037 things work
> just fine.
> 
> I suspect the culprit is r233749 and subsequent changes to build libstdc++
> as a filter library for libsupc++.
> 
> This also seems similar ot PR kern/171610.

Yes, quite possible. AFAIR, the 'catch' code compares the exception classes
by the shared object ownership. It might get confused due to filter providing
some symbols.

But I did not investigated the cause for real.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20130121/580a278c/attachment.sig>