This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author cvs-src
Recipients cvs-src
Date 2013-06-10.08:11:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>

Marcel Moolenaar ( pointed this out after committing FreeBSD revision 250991 [1], that makes the malloc(3) family of functions weak symbols. I'm citing him, because (silly me) I don't understand all of this completely:

After my commit to head that makes the malloc(3) family of functions weak symbols, a bug in what appears to be the Python build was exposed. The net effect of the bug is that contains (strong) definitions of the malloc(3) family of functions and resulting in unintended symbol resolution. incorporates the libffi functionality for what I presume is
the basis for Python bindings. libffi includes dlmalloc.c, an open source allocator. dlmalloc.c is incuded by closures.c and closures.c defines USE_DL_PREFIX. On top of that closures.c makes all allocator functions static. This, therefore adds a memory allocator to libffi without exposure of standard symbols In short: dlmalloc.c never gets compiler separately or independently for this reason.

The python build however compiles dlmalloc.c separately/independently. As such, dlmalloc.c now defines and exports the malloc(3) family of functions and it also get linked into Thus when libffi is built as part of the Python build, the set of symbols exported is different from when libffi is compiled as a port.

The simplest test case is this (on a -current machines):

1.  Build & install lang/python27 (unmodified; if needed)
2.  try and build databases/py-sqlite3

The build of databases/py-sqlite3 fails because this:
running config
*** Signal 11

On amd64 I observed an assertion failure of FreeBSD's malloc, with
the same effect.

Manually triggering this:

fbsdvm% pwd

fbsdvm% /usr/local/bin/python2.7 config
running config
Segmentation fault

But if symbols are resolved non-lazily, things change:

fbsdvm% setenv LD_BIND_NOW yes
fbsdvm% /usr/local/bin/python2.7 config
running config

This demonstrates how, after loading, malloc(3) and friends
get resolved differently and thus inconsistently from before.

The publicly visible symbols in, also show the problem:

fbsdvm% nm /usr/local/lib/python2.7/lib-dynload/ | grep ' T ' | egrep '(alloc)|(free)'
0000c3f0 T _ctypes_alloc_callback
00005250 T _ctypes_alloc_format_string
00016d10 T calloc
000121e0 T ffi_closure_alloc
00013760 T ffi_closure_free
00016050 T free
000170c0 T independent_calloc
000172d0 T independent_comalloc
000148e0 T malloc
00017460 T malloc_footprint
00017480 T malloc_max_footprint
000175c0 T malloc_stats
00017440 T malloc_trim
000176e0 T malloc_usable_size
000173a0 T pvalloc
00016d90 T realloc
00017310 T valloc

There are definitions of malloc(3) and friends that shouldn't be there.

We have similar reports in our bug-tracker [2] and [3]. And the patch attached fixes this for post-r250991 versions of FreeBSD, and noop for earlier versions. The same patch applied to python2.7, python3.2, python3.3 and patched in FreeBSD ports tree locally.

Date User Action Args
2013-06-10 08:11:18cvs-srcsetrecipients: + cvs-src
2013-06-10 08:11:18cvs-srcsetmessageid: <>
2013-06-10 08:11:18cvs-srclinkissue18178 messages
2013-06-10 08:11:17cvs-srccreate