Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Jun 2013 20:51:16 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        "current@freebsd.org list" <current@freebsd.org>
Subject:   Re: svn commit: r250991 - in head: [malloc weak symbols]
Message-ID:  <D5FA20C2-2A5C-4B0B-9A4C-AE2B9EE1167A@xcllnt.net>
In-Reply-To: <E2FC77D0-99EC-491A-99D3-CD43D28AB6CB@xcllnt.net>
References:  <201305251859.r4PIxChc053341@svn.freebsd.org> <51AC9933.7050201@FreeBSD.org> <DC0C5FC7-C9A2-4158-9560-501B96B0E5C2@xcllnt.net> <CAGE5yCqpk%2BEw4EMv5HtAEdTnq7kof0zavhWDNznihjtMr0ocAg@mail.gmail.com> <E2FC77D0-99EC-491A-99D3-CD43D28AB6CB@xcllnt.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 3, 2013, at 11:29 AM, Marcel Moolenaar <marcel@xcllnt.net> 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/libgc-redirect.so.1
dlmalloc-2.8.4.tbz:		./lib/libdlmalloc.so.2
dmalloc-5.5.2.tbz:		./lib/libdmalloc.so.1
				./lib/libdmallocth.so.1
				./lib/libdmallocthcxx.so.1
				./lib/libdmallocxx.so.1
electricfence-2.2.2_2.tbz:	./lib/libefence.so.0
gcc-4.2.5.20090325_5.tbz:	./lib/gcc42/libmudflap.so.0
				./lib/gcc42/libmudflapth.so.0
gcc-4.4.7,1.tbz:		./lib/gcc44/libmudflap.so.0
				./lib/gcc44/libmudflapth.so.0
gcc-4.6.3.tbz:			./lib/gcc46/libmudflap.so.0
				./lib/gcc46/libmudflapth.so.0
gcc-4.6.4.20130215.tbz:		./lib/gcc46/libmudflap.so.0
				./lib/gcc46/libmudflapth.so.0
gcc-4.7.3.20130323.tbz:		./lib/gcc47/libmudflap.so.0
				./lib/gcc47/libmudflapth.so.0
gcc-4.8.1.20130328.tbz:		./lib/gcc48/libmudflap.so.0
				./lib/gcc48/libmudflapth.so.0
gcc-4.9.0.20130319.tbz:		./lib/gcc49/libmudflap.so.0
				./lib/gcc49/libmudflapth.so.0
google-perftools-1.8.3.tbz:	./lib/libtcmalloc.so.2
				./lib/libtcmalloc_and_profiler.so.2
				./lib/libtcmalloc_debug.so.2
				./lib/libtcmalloc_minimal.so.2
				./lib/libtcmalloc_minimal_debug.so.2
graphviz-2.30.1.tbz:		./lib/graphviz/libgvpr.so.2
libhoard-3.8.tbz:		./lib/libhoard.so.1
lmdbg-1.1.0.tbz:		./lib/liblmdbg.so.0.0
memcheck-0.2.4.tbz:		./lib/libmemcheck.so.2
mpatrol-1.4.8_3.tbz:		./lib/libmpatrol.so.1
				./lib/libmpatrolmt.so.1
ptmalloc-3.0_1.tbz:		./lib/libptmalloc.so.3
ptmalloc2-20060605_1.tbz:	./lib/libptmalloc2.so.0
python27-2.7.3_6.tbz:		./lib/python2.7/lib-dynload/_ctypes.so
python32-3.2.3_2.tbz:		./lib/python3.2/lib-dynload/_ctypes.so
python33-3.3.0_2.tbz:		./lib/python3.3/lib-dynload/_ctypes.so
spideroak-i386-4.8.3.10016.tbz:	./share/spideroak/_ctypes.so
umem-1.0.1.tbz:			./lib/libumem_malloc.so.0

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.

FYI,

-- 
Marcel Moolenaar
marcel@xcllnt.net





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D5FA20C2-2A5C-4B0B-9A4C-AE2B9EE1167A>