From owner-svn-src-head@FreeBSD.ORG Mon Jun 3 18:30:09 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CBE6CAB8; Mon, 3 Jun 2013 18:30:09 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8E8201EB0; Mon, 3 Jun 2013 18:30:09 +0000 (UTC) Received: from sladejones-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.7/8.14.7) with ESMTP id r53IU2U9029090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Jun 2013 11:30:03 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: svn commit: r250991 - in head: contrib/jemalloc/include/jemalloc include lib/libc/stdlib/jemalloc From: Marcel Moolenaar In-Reply-To: Date: Mon, 3 Jun 2013 11:29:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201305251859.r4PIxChc053341@svn.freebsd.org> <51AC9933.7050201@FreeBSD.org> To: Peter Wemm X-Mailer: Apple Mail (2.1503) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar , Dimitry Andric , src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:30:09 -0000 On Jun 3, 2013, at 10:44 AM, Peter Wemm 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