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.
Created on 2012年02月09日 21:10 by dgoulet, last changed 2022年04月11日 14:57 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| issue13979-v0.patch | meador.inge, 2012年02月13日 03:46 | Patch against 3.2 tip | ||
| Messages (3) | |||
|---|---|---|---|
| msg152988 - (view) | Author: David Goulet (dgoulet) | Date: 2012年02月09日 21:10 | |
I'm working with the LTTng (Linux Tracing) team and we came across a problem with our user-space tracer and Python default behaviour. We provide a libc wrapper that instrument free() and malloc() and is usable with a simple LD_PRELOAD. This lib *was* named "liblttng-ust-libc.so" and we came across python software registering to our trace registry daemon (meaning that somehow the python binary is using our in-process library). We dig a bit and found this: Lib/ctypes/utils.py: def _findLib_ldconfig(name): # XXX assuming GLIBC's ldconfig (with option -p) expr = r'/[^\(\)\s]*lib%s\.[^\(\)\s]*' % re.escape(name) res = re.search(expr, os.popen('/sbin/ldconfig -p 2>/dev/null').read()) and, at least, also found in _findLib_gcc(name) and _findSoname_ldconfig(name). This cause Python to use any library ending with "libc.so" to be loaded.... I don't know the reasons behind this but we are concerned about "future issues" with this kind of behaviour. Thanks |
|||
| msg153245 - (view) | Author: Meador Inge (meador.inge) * (Python committer) | Date: 2012年02月13日 03:46 | |
'find_library' itself actually loads no libraries. I suspect what happened was that the following code in the 'uuid' module coupled with the 'find_library' bug caused 'liblttng-ust-libc.so' to be loaded: for libname in ['uuid', 'c']: try: lib = ctypes.CDLL(ctypes.util.find_library(libname)) except: continue if hasattr(lib, 'uuid_generate_random'): _uuid_generate_random = lib.uuid_generate_random if hasattr(lib, 'uuid_generate_time'): _uuid_generate_time = lib.uuid_generate_time This issue was fixed in 3.3 as a part of the optimization done in issue11258. I can still reproduce the problem in 2.7 and 3.2. I am just going to backport the 3.3 regex to 2.7 and 3.2. This is not an issue for the '_findLib_gcc' regex because the GCC output has a different format. '_findLib_ldconfig' is never actually called so I removed it. Patch attached. |
|||
| msg153329 - (view) | Author: Roundup Robot (python-dev) (Python triager) | Date: 2012年02月14日 04:25 | |
New changeset ac362fb3b86b by Meador Inge in branch '3.2': Issue #13979: Fix ctypes.util.find_library ldconfig regex http://hg.python.org/cpython/rev/ac362fb3b86b New changeset be41abd74949 by Meador Inge in branch '2.7': Issue #13979: Fix ctypes.util.find_library ldconfig regex http://hg.python.org/cpython/rev/be41abd74949 New changeset 096e856a01aa by Meador Inge in branch 'default': Issue #13979: Fix ctypes.util.find_library ldconfig regex http://hg.python.org/cpython/rev/096e856a01aa |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:26 | admin | set | github: 58187 |
| 2012年02月14日 04:27:18 | meador.inge | set | status: open -> closed resolution: fixed stage: patch review -> resolved |
| 2012年02月14日 04:25:49 | python-dev | set | nosy:
+ python-dev messages: + msg153329 |
| 2012年02月13日 15:28:10 | sbarthelemy | set | nosy:
+ sbarthelemy |
| 2012年02月13日 03:46:10 | meador.inge | set | files:
+ issue13979-v0.patch versions: - Python 3.3 messages: + msg153245 keywords: + patch stage: needs patch -> patch review |
| 2012年02月09日 21:41:09 | pitrou | set | nosy:
+ meador.inge stage: needs patch versions: + Python 3.2, Python 3.3, - Python 2.6 |
| 2012年02月09日 21:10:07 | dgoulet | create | |