From owner-freebsd-bugs@freebsd.org Thu May 14 08:14:57 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 75DC22E9250 for ; Thu, 14 May 2020 08:14:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49N48d2bmxz43CR for ; Thu, 14 May 2020 08:14:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 592F22E924F; Thu, 14 May 2020 08:14:57 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 58F482E924E for ; Thu, 14 May 2020 08:14:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49N48d1ft1z43CQ for ; Thu, 14 May 2020 08:14:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 344FE7D44 for ; Thu, 14 May 2020 08:14:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 04E8EvXc084675 for ; Thu, 14 May 2020 08:14:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 04E8Evx3084669 for bugs@FreeBSD.org; Thu, 14 May 2020 08:14:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 246462] dlopen incorrect resolution of symbols [RTLD_DEEPBIND] Date: Thu, 14 May 2020 08:14:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: d8zNeCFG@aon.at X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 08:14:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246462 Bug ID: 246462 Summary: dlopen incorrect resolution of symbols [RTLD_DEEPBIND] Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: d8zNeCFG@aon.at Introduction: This issue arose in the context of trying to upgrade a port (databases/postgresql-mysql_fdw) but is actually about the behavior of rtld/dlopen which seems to have changed (probably with the switch to clang/llvm). Scenario: - System running FreeBSD 12.1-RELEASE-p4 #4 r360692M - Ports at latest, mysql57-server and postgresql12-server installed - Trying to upgrade databases/postgresql-mysql_fdw from its current 2.5.1 to 2.5.3 Note: databases/postgresql-mysql_fdw is a foreign data wrapper which enable= s a Postgres server to access remote MySQL databases. Scenario (continued): - The upgrade is straightforward, just adapt the Makefile and distinfo, and= it compiles and can be installed. - After installation, the local database is extended to be able to access t= he remote MySQL database using CREATE EXTENSION mysql_fdw; CREATE_SERVER ... CREATE USER MAPPING ... GRANT USAGE ON FOREIGN SERVER ... CREATE SCHEMA ... IMPORT FOREIGN SCHEMA ... - Then a foreign table is accessed using SELECT * FROM ; Result: - When accessing the foreign table, the first access retrieves a correct result, and then the postgres process handling the postgres database client crashes with segmentation violation (signal 11), producing a core file. Scenario (continued): - Debugging the core file using lldb -c /tmp/postgres.core /usr/local/bin/postgres Result: (lldb) thread backtrace * thread #1, name =3D 'postgres', stop reason =3D signal SIGSEGV * frame #0: 0x00000000009002eb postgres`pfree + 11 frame #1: 0x00000000006a50de postgres`list_delete + 206 frame #2: 0x000000080b4f7d36 libmysqlclient.so`mysql_stmt_close + 102 Explanation: I believe what is happening here is that mysql_stmt_close calls list_delete, but this list_delete gets resolved to the version in the postg= res binary instead of the function of the same name in libmysqlclient.so. This = is because MySQL and Postgres are using the same names for different functions= of their own, and in this case the wrong one is being called. A while ago, when the databases/postgresql-mysql_fdw port was last upgraded some years ago, this seemingly was not the case. Specifically, in the source code of this port one finds the following comment: /* * mysql_load_library function dynamically load the mysql's library * libmysqlclient.so. The only reason to load the library using dlopen * is that, mysql and postgres both have function with same name like * "list_delete", "list_delete" and "list_free" which cause compiler * error "duplicate function name" and erroneously linking with a function. * This port of the code is used to avoid the compiler error. * * #define list_delete mysql_list_delete * #include * #undef list_delete * * But system crashed on function mysql_stmt_close function because * mysql_stmt_close internally calling "list_delete" function which * wrongly binds to postgres' "list_delete" function. * * The dlopen function provides a parameter "RTLD_DEEPBIND" which * solved the binding issue. * * RTLD_DEEPBIND: * Place the lookup scope of the symbols in this library ahead of the * global scope. This means that a self-contained library will use its * own symbols in preference to global symbols with the same name contained * in libraries that have already been loaded. */ bool mysql_load_library(void) { #if defined(__APPLE__) || defined(__FreeBSD__) /* * Mac OS/BSD does not support RTLD_DEEPBIND, but it still * works without the RTLD_DEEPBIND */ mysql_dll_handle =3D dlopen(_MYSQL_LIBNAME, RTLD_LAZY); #else mysql_dll_handle =3D dlopen(_MYSQL_LIBNAME, RTLD_LAZY | RTLD_DEEPBI= ND); #endif if(mysql_dll_handle =3D=3D NULL) return false; Conclusion: It seems that the behavior of the runtime loader changed such t= hat now the executable's symbols are searched before a library's symbols when resolving references arising from that library (in this case, libmysqlclient.so). It further seems that there are two possible resolution= s: Either re-introduce the old behavior (which made it unnecessary to use RTLD_DEEPBIND in FreeBSD), or implement RTLD_DEEPBIND for FreeBSD. -- Martin --=20 You are receiving this mail because: You are the assignee for the bug.=