http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #3 from Jeffrey Walton <noloader at gmail dot com> 2010-10-20 17:38:59 UTC --- (In reply to comment #2) > (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? > ... > 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. If a picture is worth a 1000 words, here's the scenario we are trying to accomplist (to verify Crypto++ does not crash when unloaded). But keep in mind that two distinct process will perform what's in the image. http://www.cryptopp.com/wiki/File:Cryptopp-so-test.png
