Hi All, Forgot to mention. If you have so global data that is being cleaned up prematurely, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097#c17. One of the GCC folks made the recommendations.
Jeff On Fri, Oct 22, 2010 at 2:21 AM, Jeffrey Walton <noloa...@gmail.com> wrote: > Hi All, > > 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 > > 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. The > interactions described above are specified in the Linux ABI, and > result in a One Definition Rule (ODR) violation. > > The attached tool stemmed from a feature request [1] (and another > similar problem which materialized while I was making the request [2]) > on the GCC mailing list. I requested a warning for 'global variables' > in compilation units since they [globals] are the cause of the crash > under certain circumstances. So far, the response has been RTFM. > Unfortunately, nearly 300 additional modules have not yet read the > manual, including a couple of GTK modules. > > Jeffrey Walton > Baltimore, MD, US > > [1] Switch to warn of global variables in a C++ shared object, > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097 > [2] Global variable in static library - double free or corruption > error, http://gcc.gnu.org/ml/gcc-help/2010-10/msg00248.html > > ======================================= > > [SNIP] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
