Date: Mon, 3 Jun 2013 11:29:57 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Peter Wemm <peter@wemm.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar <marcel@freebsd.org>, Dimitry Andric <dim@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r250991 - in head: contrib/jemalloc/include/jemalloc include lib/libc/stdlib/jemalloc Message-ID: <E2FC77D0-99EC-491A-99D3-CD43D28AB6CB@xcllnt.net> In-Reply-To: <CAGE5yCqpk%2BEw4EMv5HtAEdTnq7kof0zavhWDNznihjtMr0ocAg@mail.gmail.com> References: <201305251859.r4PIxChc053341@svn.freebsd.org> <51AC9933.7050201@FreeBSD.org> <DC0C5FC7-C9A2-4158-9560-501B96B0E5C2@xcllnt.net> <CAGE5yCqpk%2BEw4EMv5HtAEdTnq7kof0zavhWDNznihjtMr0ocAg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 3, 2013, at 10:44 AM, Peter Wemm <peter@wemm.org> wrote:
>>=20
>> Unfortunately, this means python needs to be recompiled from ports =
with
>> the following fix:
>>=20
>> Index: files/patch-Modules-_ctypes-libffi-fficonfig.py.in
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- files/patch-Modules-_ctypes-libffi-fficonfig.py.in (revision 0)
>> +++ files/patch-Modules-_ctypes-libffi-fficonfig.py.in (working =
copy)
>> @@ -0,0 +1,10 @@
>> +--- Modules/_ctypes/libffi/fficonfig.py.in.orig 2013-06-03 =
07:16:44.000000000 -0700
>> ++++ Modules/_ctypes/libffi/fficonfig.py.in 2013-06-03 =
07:17:03.000000000 -0700
>> +@@ -1,7 +1,6 @@
>> + ffi_sources =3D """
>> + src/prep_cif.c
>> + src/closures.c
>> +-src/dlmalloc.c
>> + """.split()
>> +
>> + ffi_platforms =3D {
>>=20
>> This has been tested with python-2.7.5. I can't say anything about
>> other versions.
>>=20
>> Do people concur that this is the right fix?
>=20
> Forgive me for asking dumb questions, but:
>=20
> * Does this fix the firefox, chromium etc problems? (were they linked
> to python?)
libffi and this _ctypes.so is (based on an educated guess) the core
of Python bindings. Anything that has a python binding is likely to
have been broken.
> * 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...
--=20
Marcel Moolenaar
marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E2FC77D0-99EC-491A-99D3-CD43D28AB6CB>