Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 May 2015 14:49:48 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 200171] lang/gcc5: Exception handling broken due to use of system libgcc_s.so
Message-ID:  <bug-200171-13@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200171

            Bug ID: 200171
           Summary: lang/gcc5: Exception handling broken due to use of
                    system libgcc_s.so
           Product: Ports & Packages
           Version: Latest
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: gerald@FreeBSD.org
          Reporter: rleigh@codelibre.net
             Flags: maintainer-feedback?(gerald@FreeBSD.org)
          Assignee: gerald@FreeBSD.org

I've tried to make a minimal test case for this but haven't succeeded as yet,
maybe I don't have the right pattern of shared libs and call stack, but I can
hopefully explain exactly what's wrong.

I've built GCC from ports (lang/gcc5), and then updated make.conf and rebuilt
all ports from scratch using gcc5, so everything under /usr/local is built by
gcc5.

My program, using xerces-c3 and consisting of a number of shared libraries,
dies when it encounters invalid input in a unit test.  The code is below, with
the site that throws an exception marked with *****.  What happens is that the
parser throws a xercesc::XMLErrs::Codes enum (which is expected).  However, the
surprising part is that it's not caught by the "catch(...)" block, or an
explicit catch for the type in question (not shown here).  Instead it
immediately aborts via abort() and verbose_terminate_handler().  This is
because the shared libraries, executables are all linked against libgcc_s.so
and ldd shows it to be using the copy from /lib (GCC4.2).  If I use
LD_LIBRARY_PATH to make it use the copy from /usr/local/lib/gcc5, then
everything works correctly.

So the essence of this bug report is basically to ask whether the GCC ports
could force the use of a newer libgcc_s.so e.g. with rpath or the like, so that
exception handling can work properly for shared libraries and programs built
with gcc from ports.  The default works for the simple case (one shared lib
and/or a standalone binary), but not for more complex cases.

  void
  read_source(xercesc::XercesDOMParser& parser,
              xercesc::InputSource&     source)
  {
    // To clean up properly due to the lack of Xerces
    // exception-safety, track if we need to throw an exception after
    // cleanup.
    bool ok = false;
    std::string fail_message;

    ome::common::xml::ErrorReporter er;
    parser.setErrorHandler(&er);

    ome::common::xml::EntityResolver res;
    parser.setXMLEntityResolver(&res);

    try
      {
        parser.parse(source); **** Exception thrown here ****
        ok = true;
      }
    catch (const xercesc::XMLException& toCatch)
      {
        fail_message = "XMLException during DOM XML parsing: ";
        fail_message += ome::common::xml::String(toCatch.getMessage());
      }
    catch (const xercesc::DOMException& toCatch)
      {
        fail_message = "DOMException during DOM XML parsing: ";
        fail_message += ome::common::xml::String(toCatch.getMessage());
      }
    catch (...) **** Exception *not* handled here ****
      {
        fail_message = "Unexpected exception during DOM XML writing";
      }

    if (!ok)
      throw std::runtime_error(fail_message);
   if (er || !parser.getDocument())
      throw std::runtime_error("Parse error");
  }

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-200171-13>