tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Replacing malloc et al in programs.



Morning Jörg,

I was afraid so, but traditional programs (also from pkgsrc, like electric fence) do not do that, instead you get compile errors.

I do not know if it is common anymore with programs replacing the the malloc() functions, but (quite) some years ago it was not uncommon for programs that used their own malloc functions.  Emacs comes to mind (which required sbrk() to be available).

There should be some (simple) way to avoid this problem.  Any ideas?

-- R

Den 2025-11-14 kl. 11:57, skrev Jörg Sonnenberger:
Hello Anders,
you need to replace the full API list including the fork hooks.

Joerg

On 11/14/25 9:48 AM, Anders Magnusson wrote:
Hi,

I just ended up in debugging a program (on NetBSD 10.1/i386) that error out in strange ways.

A simple way to get something predictable is to link it static (to avoid different placement of dynamic libs) and to link with Electric Fence (to get a quick-catch of malloc bugs).

But; it fails to link anymore.  Command line:
% gcc -static -O -L/usr/pkg/lib main.o run.o locate.o -o ragge -lefence
ld: /usr/lib/libc.a(jemalloc.o): in function `malloc':
jemalloc.c:(.text+0x3a4c): multiple definition of `malloc'; /usr/pkg/ lib/libefence.a(efence.o):/pbulk/work/devel/electric-fence/work/ electric-fence-2.1.13/efence.c:825: first defined here
ld: /usr/lib/libc.a(jemalloc.o): in function `calloc':
jemalloc.c:(.text+0x4a88): multiple definition of `calloc'; /usr/pkg/ lib/libefence.a(efence.o):/pbulk/work/devel/electric-fence/work/ electric-fence-2.1.13/efence.c:842: first defined here
....

This suggests that either jemalloc has been too deeply integrated into libc (so that it cannot even be changed) or that there is some bug in ld? How is replacement of the malloc routines supposed to be done these days?

-- R




Home | Main Index | Thread Index | Old Index