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 dgoulet
Recipients dgoulet
Date 2012-02-09.21:10:06
SpamBayes Score 6.215158e-10
Marked as misclassified No
Message-id <1328821808.41.0.811189579105.issue13979@psf.upfronthosting.co.za>
In-reply-to
Content
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
History
Date User Action Args
2012-02-09 21:10:08dgouletsetrecipients: + dgoulet
2012-02-09 21:10:08dgouletsetmessageid: <1328821808.41.0.811189579105.issue13979@psf.upfronthosting.co.za>
2012-02-09 21:10:07dgouletlinkissue13979 messages
2012-02-09 21:10:06dgouletcreate