Changes between Version 1 and Version 2 of Ticket #44, comment 14


Ignore:
Timestamp:
2012-02-13T01:23:52Z (13 years ago)
Author:
zooko
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #44, comment 14

    v1 v2  
    1 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. Here are the test results from two systems in the new build with Wei Dai's patch applied: [https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora/builds/27] and [https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora/builds/27].
     1Well, 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. Here are the test results from one of those two systems in the new build with Wei Dai's patch applied: [https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora/builds/27].
    22
    33I 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.