http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #2 from Jeffrey Walton <noloader at gmail dot com> 2010-10-20 17:33:43 UTC --- (In reply to comment #1) > (In reply to comment #0) > > When a module meets the above compile and runtime requirements, a crash can > > occur in global objects with destructors when more than one process loads > > and > > subsequently unloads a shared object. > Are you saying independent processes interfere with each other? Yes and No :/ If each process loads the SO with RTLD_LOCAL, then No. If the processes each load with RTLD_GLOBAL (so an exception can be caught) *AND* the SO has an non-trivial global (such as an object with a destructor) then YES. Crpyto++ has a test case demonstrating the RTLD_GLOBAL crash at [1]. [1] is accompanied by an analysis under GDB at [2]. Unfortunately, the test case is not minimal. It is based on the Crypto++ library and needs intermediate SOs to load the SO of interest. So the final executable never directly loads the Crypto++ shared object. Based on the demonstartion, Wei Dai modified global objects so that only PODs were global. Non-trivial objects were hidden in a GetGlobalXxx() (some hand waiving). A write up distribution packagers (from our understanding of the moving parts) is available at [3,4]. [1] http://www.cryptopp.com/w/images/8/89/Cryptopp-SO-Test-1.zip [2] http://groups.google.com/group/cryptopp-users/browse_thread/thread/7eae009a4e02e726 [3] http://www.cryptopp.com/wiki/Linux#Note_for_Shared_Object_Callers [4] http://www.cryptopp.com/wiki/Linux#Note_for_Distribution_Packagers
