[cursed email aliases!]
On Tue, Aug 24, 2021 at 10:42 AM Siddhesh Poyarekar <sipoyare(a)redhat.com> wrote:
On Tue, Aug 24, 2021 at 2:52 AM Richard W.M. Jones <rjones(a)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