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

Reply via email to