[cursed email aliases!]
On Tue, Aug 24, 2021 at 10:42 AM Siddhesh Poyarekar sipoyare@redhat.com wrote:
On Tue, Aug 24, 2021 at 2:52 AM Richard W.M. Jones rjones@redhat.com wrote:
Anyway this is not the reason why I'm writing this email on Fedora devel list. In the Fedora package we have:
$ rpm -qf /usr/lib64/libc_malloc_debug.so glibc-devel-2.34-1.fc35.x86_64 $ rpm -qf /usr/lib64/libc_malloc_debug.so.0 glibc-2.34-1.fc35.x86_64
I'm wondering why it was decided to put the symlink and the file in the two different packages?
Is it intended that end users use:
LD_PRELOAD=/usr/lib64/libc_malloc_debug.so.0 # (1)
This one is correct.
or
LD_PRELOAD=/usr/lib64/libc_malloc_debug.so # (2)
If it's (1) then that is a file, so why bother with the symlink?
I have an open bug and PR to resolve this:
https://bugzilla.redhat.com/show_bug.cgi?id=1985048 https://src.fedoraproject.org/rpms/glibc/pull-request/37
I waited because we were too close to the mass rebuild and then it fell off my plate, sorry :/
If it's (2) then that's a symlink to (1), so why have the possibility of installing only the glibc package thus getting only the file /usr/lib64/libc_malloc_debug.so.0 which is not useful on its own?
Also is this feature intended for developers (glibc-devel) or everyone (glibc)? (My preference is "everyone" - we've found that asking bug reporters to enable MALLOC_CHECK_ in an ad hoc way can be a good way to see if a bug is a memory corruption problem.)
The intent is to separate debugging from core functionality to improve security and performance (and make it easier for us to improve malloc in future but that's unrelated in this context), so it will likely end up in glibc-utils (that's where mtrace is) or its own package. That will give administrators the option to remove libc_malloc_debug.so.0 from the system. We (i.e. glibc package maintainers) are yet to agree on the right place for this, mainly due to forgetting about it after the mass rebuild.
Siddhesh