Please help with filing a bug against glibc, I have privacy concerns
|
04-21-2021, 04:18 PM
(This post was last modified: 04-22-2021 09:07 AM by 3298.)
Post: #1
|
|||
|
|||
Please help with filing a bug against glibc, I have privacy concerns
I recently ran into a glibc bug, but there's a little something in the bug tracker's registration procedure that prevents me from reporting it.
Quote:Activity on most bugs, including email addresses, will be visible.(Emphasis mine.) Exposing private info like a mail address is where the fun stops - no way I'll register there. This forum, by contrast, lets me hide my mail address, just like many other places on the web do. Even public git repositories technically don't need an address that actually accepts mail, a no-reply or invalid one generally works fine. Privacy rant aside, I'd still like to get the bug fixed. I do have a patch ... That means I now need someone who's less concerned about privacy to forward a bug report. I'm not as picky about attribution for the discovery and the fix - when you know what's going wrong, it's just a trivial two-liner anyway. Details follow, in a format that should make it easy to simply insert into the bug template (though maybe the two code boxes could be supplied as attached files instead of or in addition to inline text): Product: glibc Component: dynamic-linker OS: All Summary: Inconsistency detected by ld.so: dl-fini.c: 88: _dl_fini: Assertion `ns != LM_ID_BASE || i == nloaded' failed! Description: Overview: The dynamic linker's finalizer crashes if it's not (directly or indirectly) in the library dependencies of the loaded application. Steps to reproduce: Compile and run a self-contained program calling the dynamic linker's finalizer (received in %rdx on x86-64 according to the ABI docs) before exit, with link options specifying that a dynamic linker shall be used, but without linking to something that pulls in the dynamic linker itself (be careful: libc.so.6 does), e.g. with these GCC options: -nostdlib -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 Code: # filename: dl_fini_assert_nloaded_test.S Actual Results: Crash, with the assertion failure message listed above. Expected Results: Clean exit. Build Date & Hardware: 2021-04-21 on Arch Linux - glibc version: 2.33 (as tested; should affect every version since 2.2) - kernel: Linux 5.11 (as tested; should not matter for the glibc code, but my test case assumes Linux for the exit syscall and for the linker options) - architecture: x86-64 (as tested; should not matter for the glibc code, but my assembly test case clearly needs it) - compiler and linker versions: GCC 10.2.0, ld 2.36.1 (as tested; shouldn't matter for the glibc code, but my test case is written with GCC in mind) Additional Information: I tracked this issue down to where the rtld function dl_main temporarily adds the rtld itself to the list of loaded libraries, then removes it later if it's not in the dependencies of other libraries loaded in the meantime. libc.so.6 does have such a dependency, so this code path is rarely used, because almost all software uses the shared version of the C standard library in some way or is statically linked (in the latter case, the rtld generally isn't used to launch the software in the first place). The bug is simply that during removal the counter for loaded objects isn't decremented. This mismatch then gets noticed when the rtld finalizer is called, triggering an assertion. The bug exists since commit 1ebba33ece5a998d3d79fa14adca3ae7985cbff5 made way back in August 2000, which introduced this counter. There are sporadic occurences of the crash message on the web, e.g. in the FreePascal bug tracker, but apparently nobody went the extra mile to properly report or fix it. Code: # filename: dl_fini_assert_nloaded_fix.diff |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)