New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redefinition of malloc(3) family of functions at build time #62378
Comments
Hello. Marcel Moolenaar (marcel@FreeBSD.org) 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: """ _ctypes.so incorporates the libffi functionality for what I presume is 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 _ctypes.so. 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):
The build of databases/py-sqlite3 fails because this: On amd64 I observed an assertion failure of FreeBSD's malloc, with Manually triggering this: fbsdvm% pwd fbsdvm% /usr/local/bin/python2.7 setup.py config But if symbols are resolved non-lazily, things change: fbsdvm% setenv LD_BIND_NOW yes This demonstrates how, after loading _ctypes.so, malloc(3) and friends The publicly visible symbols in _ctypes.so, also show the problem: fbsdvm% nm /usr/local/lib/python2.7/lib-dynload/_ctypes.so | grep ' T ' | egrep '(alloc)|(free)' 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. [1] http://svnweb.freebsd.org/changeset/base/250991 |
Said simpler: dlmalloc.c code is indeed compiled twice:
The second one is not necessary, of course. The patch looks good to me. |
I don't have a system affected by the change, but the explanation and the patch look right to me. FWIW, the patch applies cleanly to 3.4 head and passes 'make test'. |
I've added a new FreeBSD 10.0-CURRENT buildbot to the pool (thanks antoine) that reproduces the issue and should provide sufficient coverage for testing the proposed patch: http://buildbot.python.org/all/buildslaves/koobs-freebsd10 I'll upgrade the FreeBSD 9-STABLE buildbot once this is resolved |
New changeset f09ca52747a6 by Christian Heimes in branch '3.3': New changeset bea2f12e899e by Christian Heimes in branch 'default': New changeset d4ac6eee7061 by Christian Heimes in branch '2.7': |
Commit looks good, confirming test suite passing for 3.x, 3.3 and 2.7.on http://buildbot.python.org/all/buildslaves/koobs-freebsd10 Thank you for picking this up and finishing it off Christian. |
Thx for the fix! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: