From owner-freebsd-ports-bugs@FreeBSD.ORG Wed May 13 14:49:48 2015 Return-Path: Delivered-To: freebsd-ports-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A16D852A for ; Wed, 13 May 2015 14:49:48 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AFA213B0 for ; Wed, 13 May 2015 14:49:48 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4DEnmv9053536 for ; Wed, 13 May 2015 14:49:48 GMT (envelope-from bugzilla-noreply@freebsd.org) 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 Date: Wed, 13 May 2015 14:49:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rleigh@codelibre.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter flagtypes.name Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 14:49:48 -0000 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.