[tahoe-lafs-trac-stream] [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:  reopened
Priority:  major   |      Milestone:  0.6.0
 Version:  0.5.19  |     Resolution:
Keywords:          |  Launchpad Bug:
-------------------+--------------------------

Comment (by zooko):

 Well, this is pretty disappointing. I applied
 [http://bazaar.launchpad.net/~zooko/cryptopp/trunk/revision/466] as
 [https://github.com/zooko/pycryptopp/commit/95c78ce5f08b03be70e5d69e5eb09d7acc1ce420],
 and it didn't change anything in terms of test results! In particular, the
 two systems that had valgrind warnings with the old version have the exact
 same warnings with the new version: [https://tahoe-lafs.org/buildbot-
 pycryptopp/builders/Ruben%20Fedora/builds/27] and [https://tahoe-lafs.org
 /buildbot-pycryptopp/builders/Ruben%20Fedora/builds/27].

 I had thought that those valgrind warnings were due to the problem of
 handling global symbols and singletons. In fact, now that I think about
 it, what exactly did I think was happening here? I guess on Linux the
 module loading flags default to {{{RTLD_LOCAL}}} instead of
 {{{RTLD_GLOBAL}}}, which I think should be causing a failure of cross-
 module typeinfo comparison (e.g. a failure to catch an exception of a
 certain type, raised in a different C++ module), but there isn't such a
 failure demonstrated by the tests.

 In contrast if the flag was set to {{{RTLD_GLOBAL}}} then I would have
 expected exception-catching to work, but multiple libraries which
 dynamically link to the Crypto++ dynamic link library would each think
 they were solely responsible for managing the global symbols in that
 library, including constructing and destructing singletons, which should
 lead to some problems, most importantly a double-free problem. I don't see
 that either, on the buildbots, although possibly that's because none of
 the systems is using {{{RTLD_GLOBAL}}} now.

 Okay, now what? The pressing questions are:

 * what these valgrind warnings mean (pasted into this comment below),
 * why Wei Dai wrote that patch,
 * why we no longer get a problem where exceptions raised from one module
 can't be caught (by their type) in another module,
 * if the current version of pycryptopp triggers a double-free error (or
 another critical problem) when it and another library (e.g. another Python
 module) are loaded into the same process and linking to the same Crypto++
 DLL

 Help!

 {{{
 ==30887== Conditional jump or move depends on uninitialised value(s)
 ==30887==    at 0x4017A16: index (in /lib64/ld-2.15.so)
 ==30887==    by 0x4007927: expand_dynamic_string_token (in
 /lib64/ld-2.15.so)
 ==30887==    by 0x40081BC: _dl_map_object (in /lib64/ld-2.15.so)
 ==30887==    by 0x400171D: map_doit (in /lib64/ld-2.15.so)
 ==30887==    by 0x400EB65: _dl_catch_error (in /lib64/ld-2.15.so)
 ==30887==    by 0x4000EE3: do_preload (in /lib64/ld-2.15.so)
 ==30887==    by 0x4003EB2: dl_main (in /lib64/ld-2.15.so)
 ==30887==    by 0x4014E4A: _dl_sysdep_start (in /lib64/ld-2.15.so)
 ==30887==    by 0x4004E71: _dl_start (in /lib64/ld-2.15.so)
 ==30887==    by 0x4001537: ??? (in /lib64/ld-2.15.so)
 ==30887==    by 0x1: ???
 ==30887==    by 0x7FF000E96: ???
 }}}

-- 
Ticket URL: <http://tahoe-lafs.org/trac/pycryptopp/ticket/44#comment:14>
pycryptopp <https://tahoe-lafs.org/trac/pycryptopp>