public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30981] New: dlclose does not properly implement force-first handling Date: Wed, 18 Oct 2023 14:38:10 +0000 [thread overview] Message-ID: <bug-30981-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=30981 Bug ID: 30981 Summary: dlclose does not properly implement force-first handling Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: dynamic-link Assignee: unassigned at sourceware dot org Reporter: fweimer at redhat dot com Target Milestone: --- The ELF destructor for the dlclose'd object should run first, but that does not happen due to two factors: The array passed to _dl_sort_maps is gathered from the linked list of all shared objects. In case of cycles and an unfortuate dlopen/dlclose order, the first array element may not be the link map passed to dlclose, so the force_first flag does not have the intended effect. Inside _dl_sort_maps_dfs, the relocation dependency sorting (for_fini mode) has early returns which bypass the force_first flag processing further down in the function's source code. This means that force_first may not have any effect if for_fini is active. Fixing these two issues changes the results of the existing tst-bz15311 test case: -output(glibc.rtld.dynamic_sort=1): {+a[d>c>b>a>];+e[e>];+f[f>];+g[g>];+d[];%d(b(e(a()))a()g(c(a()f(b(e(a()))))));-d[];-g[];-f[];-e[];-a[<a<c<d<g<f<b<e];} -output(glibc.rtld.dynamic_sort=2): {+a[d>c>b>a>];+e[e>];+f[f>];+g[g>];+d[];%d(b(e(a()))a()g(c(a()f(b(e(a()))))));-d[];-g[];-f[];-e[];-a[<g<f<a<b<c<d<e];} +output(glibc.rtld.dynamic_sort=1): {+a[d>c>b>a>];+e[e>];+f[f>];+g[g>];+d[];%d(b(e(a()))a()g(c(a()f(b(e(a()))))));-d[];-g[];-f[];-e[];-a[<a<b<c<d<g<f<e];} +output(glibc.rtld.dynamic_sort=2): {+a[d>c>b>a>];+e[e>];+f[f>];+g[g>];+d[];%d(b(e(a()))a()g(c(a()f(b(e(a()))))));-d[];-g[];-f[];-e[];-a[<a<g<f<b<c<d<e];} In the glibc.rtld.dynamic_sort=1, the lack of nice abcd destructor ordering was historically blamed on a sorting algorithm deficiency, while in reality it seems to be a result of the incorrect way _dl_sort_maps was called by dlclose (the first issue described above). -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2023-10-18 14:38 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-10-18 14:38 fweimer at redhat dot com [this message] 2023-10-18 14:50 ` [Bug dynamic-link/30981] " sam at gentoo dot org 2023-10-19 7:03 ` fweimer at redhat dot com 2023-11-16 18:57 ` fweimer at redhat dot com 2023-11-16 19:19 ` fweimer at redhat dot com 2023-11-20 12:11 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-30981-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).