svn commit: r250991 - in head: [malloc weak symbols]

Marcel Moolenaar marcel at
Fri Jun 7 03:51:29 UTC 2013

On Jun 3, 2013, at 11:29 AM, Marcel Moolenaar <marcel at> wrote:
>> * Even if the python code is wrong, is this one of those things that's
>> going to keep biting us going forward?  Interactions between
>> dlopen/dlsym/rtld/library dependencies/embedded malloc
>> replacements/etc has been accumulated a large number of casualties
>> over the years.
> Possibly. We do not seem to have ever had weak symbols for malloc()
> et al. Any shared library that exports malloc() and/or friends is
> potentially causing breakages. Those are breakages only seen on
> FreeBSD, I would think.
> I can do some analysis if people prefer. All it takes is the complete
> set of packages and run nm on any ELF files to see if malloc() or
> friends is defined as a global symbol to havea protential problem.
> With a bit of scripting we can come up with a list of candidates.
> We can go from there...

Ok, this is what I found:

Total packages:				23105 (stable-9-latest)
Packages with ELF files:		12492
Packages with malloc definitions:	60
	malloc in shared libraries:	24

boehm-gc-redirect-7.1.tbz:	./lib/
dlmalloc-2.8.4.tbz:		./lib/
dmalloc-5.5.2.tbz:		./lib/
electricfence-2.2.2_2.tbz:	./lib/
gcc-	./lib/gcc42/
gcc-4.4.7,1.tbz:		./lib/gcc44/
gcc-4.6.3.tbz:			./lib/gcc46/
gcc-		./lib/gcc46/
gcc-		./lib/gcc47/
gcc-		./lib/gcc48/
gcc-		./lib/gcc49/
google-perftools-1.8.3.tbz:	./lib/
graphviz-2.30.1.tbz:		./lib/graphviz/
libhoard-3.8.tbz:		./lib/
lmdbg-1.1.0.tbz:		./lib/
memcheck-0.2.4.tbz:		./lib/
mpatrol-1.4.8_3.tbz:		./lib/
ptmalloc-3.0_1.tbz:		./lib/
ptmalloc2-20060605_1.tbz:	./lib/
python27-2.7.3_6.tbz:		./lib/python2.7/lib-dynload/
python32-3.2.3_2.tbz:		./lib/python3.2/lib-dynload/
python33-3.3.0_2.tbz:		./lib/python3.3/lib-dynload/
spideroak-i386-	./share/spideroak/
umem-1.0.1.tbz:			./lib/

Most of those are intended to replace the standard memory allocator.
The exception being: graphviz, python & spideroak.

We know python got broken and it's being fixed. This leaves 2 ports
that we should definitely analyze.


Marcel Moolenaar
marcel at

More information about the freebsd-current mailing list