From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9E55938582BA; Mon, 15 Aug 2022 09:23:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9E55938582BA From: "fweimer at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/28937] New DSO dependency sorter does not put new map first if in a cycle Date: Mon, 15 Aug 2022 09:23:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.35 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fweimer at redhat dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: fweimer at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: short_desc assigned_to flagtypes.name bug_status 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 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2022 09:23:52 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28937 Florian Weimer changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|New DSO dependency resolver |New DSO dependency sorter |buggyness with dlclose() |does not put new map first | |if in a cycle Assignee|unassigned at sourceware dot org |fweimer at redhat d= ot com Flags| |security- Status|WAITING |ASSIGNED --- Comment #9 from Florian Weimer --- I could get it to boot in UEFI mode, but the disk has to be attached as sata (not virtio). Thank you for putting together this reproducer, it is really helpful. The situation matches the one described in comment 0. There is no dlclose c= all for libfreetype.so.6, so libbz2.so.1.0 really can't been unloaded. A comment in _dl_close_worker alludes to the root cause: /* We are always the zeroth entry, and since we don't include ourselves in the dependency analysis start at 1. */ struct link_map **lp =3D &l->l_initfini[1]; The assumption is not correct in this case, l_initfini[0] is actually libbz2.so.1.0 here. The reason is that the new algorithm does not implement skipping, and due to the cyclic dependency between libfreetype.so.6 and libharfbuzz.so.0, libfreetype.so.6 is not sorted first naturally. I think it makes sense to always initialize the newly-loaded object first, = but as the comment in _dl_sort_maps_dfs explains, that algorithm cannot skip the dependencies directly. But I think we should adjsut _dl_sort_maps_dfs becau= se the initialization order property seems useful. I'll try to come up with a patch. --=20 You are receiving this mail because: You are on the CC list for the bug.=