From owner-freebsd-current@FreeBSD.ORG Fri Jun 7 03:51:29 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 989879F9 for ; Fri, 7 Jun 2013 03:51:29 +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 68E3D172C for ; Fri, 7 Jun 2013 03:51:29 +0000 (UTC) Received: from dkwok-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 r573pK3p048808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Jun 2013 20:51:22 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: svn commit: r250991 - in head: [malloc weak symbols] From: Marcel Moolenaar In-Reply-To: Date: Thu, 6 Jun 2013 20:51:16 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <201305251859.r4PIxChc053341@svn.freebsd.org> <51AC9933.7050201@FreeBSD.org> To: "current@freebsd.org list" X-Mailer: Apple Mail (2.1508) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 03:51:29 -0000 On Jun 3, 2013, at 11:29 AM, Marcel Moolenaar 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