Are you saying that on x64, when cryptopp.dll gets loaded into a second
process, it retains its static data from the first instance? I don't see how
that's possible, since every Windows process gets its own address space, and
shouldn't share any memory with any other process (unless you specifically
call some APIs to do so).
--------------------------------------------------
From: "WebDrive" <[email protected]>
Sent: Wednesday, July 14, 2010 6:48 PM
To: "Crypto++ Users" <[email protected]>
Subject: Re: FIPS version on x64
Update:
I think I've tracked it down; When cryptopp.dll (FIPS) is loaded into
memory, and a 'new' call is made, cryptopp will check it's static
s_pNew global and if null, then call SetNewAndDeleteFunctionPointers()
which will then register the s_pNew and s_pDelete vars. It will then
optionally call SetNewAndDeleteFromCryptoPP() to send those pointers
over to the instantiating process. This works fine for the first
instance that loads cryptopp but for any subsequent instance that
loads cryptopp, the static s_pNew variable is !null so
SetNewAndDeleteFunctionPointers() is not called and thus
SetNewAndDeleteFromCryptoPP is not called.
What ends up happening is that the new/delete function pointers in
cryptopp are not pushed to the second/third/fourth instantiating
process that loads the DLL. So when the second instantiating process
tries to execute cryptopp code that does new/delete, the pointers are
null and the dll crashes.
Has anyone else seen this behavior?
--
You received this message because you are subscribed to the "Crypto++
Users" Google Group.
To unsubscribe, send an email to
[email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
