I can't say I'm a huge fan of the new libc_malloc_debug.so library
which is now required to do malloc checking:
* Debugging features in malloc such as the MALLOC_CHECK_ environment
variable (or the glibc.malloc.check tunable), mtrace() and mcheck()
have now been disabled by default in the main C library. Users
looking to use these features now need to preload a new debugging
DSO libc_malloc_debug.so to get this functionality back.
[from https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html]
I just added this to a project and it's a lot more work than the old way:
https://gitlab.com/nbdkit/nbdkit/-/commit/362e0fdcae37db876e13b944102a5c152e6bc563
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)
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?
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.)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
