[tahoe-dev] [pycryptopp] #44: test what happens if another Python module loads Crypto++ dynamic link library

[pycryptopp]

#44: test what happens if another Python module loads Crypto++ dynamic link
library
------------------------+---------------------------------------------------
     Reporter:  zooko   |      Owner:        
         Type:  defect  |     Status:  new   
     Priority:  major   |    Version:  0.5.19
   Resolution:          |   Keywords:        
Launchpad Bug:          |  
------------------------+---------------------------------------------------

Comment (by zooko):

 Okay, I've added a test of this. setup.py will build another .so, named
 {{{_testdoubleload.so}}}, if you pass the {{{--test-double-load}}}
 argument on the command-line. I updated the buildbot to build with
 {{{--test-double-load}}} and then to try this command-line:
 {{{
 python -c 'import pycryptopp; import _testdoubleload'
 }}}
 On many systems this causes a memory management error. It is typically
 reported as a double free detected by glibc. Here are the details reported
 by with valgrind on an Ubuntu 10.04 amd64 box:
 {{{
 Invalid read of size 4
    at 0x75BA116: std::basic_string<char, std::char_traits<char>,
 std::allocator<char> >::~basic_string() (in /usr/lib/libstdc++.so.6.0.13)
    by 0x5AC9261: exit (exit.c:78)
    by 0x5AAEC53: (below main) (libc-start.c:258)
  Address 0x7ab1210 is 16 bytes inside a block of size 28 free'd
    at 0x4C27DCF: operator delete(void*) (vg_replace_malloc.c:387)
    by 0x75BA128: std::basic_string<char, std::char_traits<char>,
 std::allocator<char> >::~basic_string() (in /usr/lib/libstdc++.so.6.0.13)
    by 0x5AC9261: exit (exit.c:78)
    by 0x5AAEC53: (below main) (libc-start.c:258)
 }}}

 Now if I force {{{use_RTLD_GLOBAL}}} to {{{False}}}
 [source:trunk/pycryptopp/__init__.py at 707#L22 on line 22 of
 pycryptopp/__init__.py] then the error goes away. Next I ran this
 experiment (with {{{use_RTLD_GLOBAL}}} at its default setting) on all of
 the buildslaves. The results were that, among unixy platforms, CentOS5,
 debian-lenny-c7-i386, Mac 10.6/amd64, OpenSolaris/amd64,
 OpenBSD-4.6/amd64, and NetBSD5/i386 showed no problems, but Ubuntu
 10.04/amd64 showed the problem.

 (See the buildbot around this time: http://tahoe-lafs.org/buildbot-
 pycryptopp/waterfall?show_events=true&last_time=1283631265 .)

 Next I'm going to push a patch to pycryptopp trunk which disables the
 RTLD_GLOBAL hack and see if that breaks anything.

-- 
Ticket URL: <http://allmydata.org/trac/pycryptopp/ticket/44#comment:4>
pycryptopp <http://allmydata.org/trac/pycryptopp>
Python bindings for the Crypto++ library