> I helped Wei Dai wrestle with a similar problem for Crypto++. We wrote > a couple audit tools, one of which is attached. I just completed an > audit on my /usr/lib. The following OpenSSL modules crashed during a > simple load/unload cycle: > > /usr/lib/debug/lib/libcrypto.so.0.9.8 > /usr/lib/debug/lib/libssl.so.0.9.8 > /usr/lib/debug/usr/lib/ssl/engines/lib4758cca.so > /usr/lib/debug/usr/lib/ssl/engines/libaep.so > /usr/lib/debug/usr/lib/ssl/engines/libatalla.so > /usr/lib/debug/usr/lib/ssl/engines/libcapi.so > /usr/lib/debug/usr/lib/ssl/engines/libchil.so
Have you seen ticket #2325? Google for "[openssl.org #2325]"... Even though it discusses libssl, engines should be affected too... Is it possible that you experience same problem? In which order were libraries loaded when IsKnownToCrash was composed? Can you confirm that loading/unloading libcrypto *alone* is problematic? In such case can you provide stack backtrace? > Since OpenSSL is a C library, a packager could be doing something with > side effects. Or if there are globals and an Uninitialize function, > the function might be whacking data that's still in use. > > In the Crypto++ case, there was a global object with a destructor that > would destroy an object during unload. No problem, since that's what > destructors do. However, if you want to catch a C++ exception across a > module boundary, you need RTLD_GLOBAL. But RTLD_GLOBAL causes the > runtime linker-loader to fold non-private symbols into one. So if two > processes have the shared library open, both processes will call the > dtor on the same object. The first will exit cleanly, the second > process will continue to run [for a while] with a bad object. ??? Objects belonging to different processes reside in disjoint address spaces, and destructor executed in one process context has no effect on corresponding object in another. Well, unless second process was created with vfork (but vfork should/may be used only for immediate exec) or object was created in MAP_SHARED or shmat-ed memory (in which case destruction should be controlled by reference counter and not by library unload). If either is case, then it's plain wrong and should be fixed. I mean it's plain wrong to use vfork or objects in explicitly shared memory in such way. > The > interactions described above are specified in the Linux ABI, and > result in a One Definition Rule (ODR) violation. At present neither of openssl shared libraries have destructor. Though I'm considering adding destructor to address above mentioned #2325... A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
