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>