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

pycryptopp trac at allmydata.org
Sat Sep 4 21:45:25 UTC 2010


#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 disabled {{{RTLD_GLOBAL}}} in [20100904201728-92b7f-
 1d838bc41934d7375fe2e611470a4e4c56185c49] and the buildbots look perfectly
 happy, e.g. http://tahoe-lafs.org/buildbot-
 pycryptopp/waterfall?show_events=true&last_time=1283634414

 Of the unixy platforms, it appears that all of the ones that were working
 back when he had {{{RTLD_GLOBAL}}} are still working, and the one that was
 failing -- Ubuntu 10.04/amd64 -- is now working.

 Does this mean that the problem that we were originally trying to fix when
 we introduced the {{{RTLD_GLOBAL}}} hack back in [20090527235925-92b7f-
 c7b71c236b9ca5ed4083327793cdea27c3201b32], problems with RTTI crossing
 shared-library boundaries, are fixed? Perhaps we no longer throw C++
 exceptions in one shared-library (libcryptopp.so) and attempt to catch
 them in another (pycryptopp.so)? Hm a quick grep tells me that we are
 attempting to catch exceptions, in pycryptopp, which were thrown by
 libcryptopp, for example:

 [source:trunk/pycryptopp/cipher/aesmodule.cpp at 702#L116 in AES
 initialization]

 Does this mean we don't have test coverage of this behavior? No, look,
 there are some right there in
 [source:trunk/pycryptopp/test/test_aes.py at 692#L38 test_aes.py]. So does
 this mean that the C++ compiler (g++) has gotten smarter about making
 cross-shared-lib RTTI work since a year ago?

 Hm. I'm not sure what's going on. I guess as long as I don't see evidence
 of a current problem (especially evidence in the form of a red unit test
 on our buildbot), I'll leave the {{{RTLD_GLOBAL}}} hack turned off for
 now.

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


More information about the tahoe-dev mailing list