http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-20 23:48:33 UTC --- (In reply to comment #6) > Hi Johnathon, > (In reply to comment #5) > > oh, and I only see one process invovled there ... I'm still confused about > > the > > claim that more than one process is involved... > My bad - the image only depicts one process. However, the first thing main() > does is a fork to get two processes in play. No fork() in the first zipfile I looked at (from [1] in comment 2), and unless the globals use something inter-process such as semaphores or file locking, there is no way they should interfere with globals in other processes. Using RTLD_GLOBAL, exceptions or RTTI doesn't change the fact that processes have their own memory space. > Try crypto++ 5.6.0 (which _had_ global objects) located at > http://www.cryptopp.com/cryptopp560.zip. Crypto 5.6.1 fixed the global object > problem. > The stress test which should trigger the issue (depicted in the image) is > located at http://www.cryptopp.com/w/images/b/be/Cryptopp-SO-Test.zip. Ah, I tried that stress test against 5.6.1 as that's what my distro provides. That stress test *does* use fork, but didn't crash for me. If I get time tomorrow I'll try it against 5.6.0 I'm probably taking this enhancement request waaaay off-topic, I just want to convince myself you're not wasting time asking for a warning that won't help prevent user error