From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C71803858C66; Mon, 6 Mar 2023 15:52:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C71803858C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678117959; bh=CiiFbZlbkjfGtGRpzyAaQpOcbk6MAbv6i9+GcTgyF08=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DSVJsOBMzs6PmdX4PIvyIrXS5zCMV7ycb3y5hqLYAqtYaotGV2NtKteZZQijJv78C x7udJ4Z3yryTo/jdkd0ZUuaqv4JsHoScizU+HulDI0DYQ+V1AVq/hj0ZSpBTL8+qLn ex5djm2oH+J/1GRagqwRrrYHORkUOQR6s1USGQWs= From: "fweimer at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug malloc/25533] dlopen with RTLD_DEEPBIND crashes when using custom memory manager Date: Mon, 06 Mar 2023 15:52:38 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: malloc X-Bugzilla-Version: 2.12 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fweimer at redhat dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: WONTFIX X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D25533 --- Comment #8 from Florian Weimer --- (In reply to Simon Richter from comment #7) > Rereading the documentation of RTLD_DEEPBIND, I'm even slightly confused = why > applying RTLD_DEEPBIND to an object will also pull the symbols of its > dependencies to the front (so glibc's "realloc" wins over libtbbmalloc's,= as > libudev is only linked against glibc). I would have expected libudev's > symbols to take precedence for internal resolution, and then the same ord= er > as in the rest of the program for the other symbols. We discussed this during today's patch review call. The issue here is that = some (many?) uses of RTLD_DEEPBIND depend on this altered symbol resolution behavior: the newly loaded object is supposed to bind against the symbols of its dependencies as if there was nothing else in the process image, to avoid unwanted preemption. In some cases, this is even done to prevent preemption coming from LD_PRELOAD. For malloc, this is pretty much never going to work, but it might be exactly what's needed for other libc symbols. It's hard to = tell where to draw the line. --=20 You are receiving this mail because: You are on the CC list for the bug.=