ByrdThe current (4.0.3) build of TurboActivate, when compiled in static x64 debug mode, crashes when calling TA_GetPDetsFromByteArray(). The culprit is actually CryptoPP, upon which TurboActivate depends.
Call stack at crash time: https://postimg.org/image/vz54137h3/
The crash in question happens in the function CryptoPP::Rijndael::Enc::AdvancedProcessBlocks() function, where _freea() is called. This is the Windows equivalent to the alloc() function. The memory is only allocated within the AdvancedProcessBlocks() function itself, so corruption from outside that stack frame is definitely not what is occurring.
The CryptoPP team has been doing lots of assembly optimization in this function, and apparently it's overoptimized for the x64 release.
An easy and fast workaround would be for you to always compile your dependent CryptoPP library with the following flags:
#define CRYPTOPP_DISABLE_ASM#define CRYPTOPP_DISABLE_SSE2
And this would take the slower but better tested code path on this function.
Please let me know when you've recompiled your libraries with this fix in place. Thank you very much!
Thanks for reporting this. We'll look into it on Monday and try to find the cause and maybe contribute back to cryptopp.
In the meantime can you try again with TurboActivate 4.0.4, released a couple of days ago. We included an updated version of that library.
Also, if you still have a crash in 4.0.4, can you shoot me an email with your TurboActivate.dat file?
Also, can you tell me which VS version you're using? 2015?
My email is wyatt@wyday.com
ByrdI tried updating to 4.0.4 and got the same crash as before. Builds in release mode do not have this problem; the assert only occurs in debug mode. This is probably because, although the _freea() call trashes the stack in CryptoPP, the corrupted memory is destroyed anyway upon exiting the function.
I've emailed you my current PDets file.
Until this gets sorted, please consider disabling this fast code path in CryptoPP::Rijndael::Enc::AdvancedProcessBlocks() . -- you're not encoding that much information anyway.
We can't reproduce this. We tried VS 2015, the debug X64 build, using the latest version (4.0.4) and everything works as expected. The data is loaded correctly (without a crash) and everything proceeds normally.
Can you send us a project that can reproduce this. Preferably something simple where you load your TurboActivate.dat from disk into a byte array, and then call TF_PDetsFromByteArray()?
You can send it to support@wyday.com and we'll take a look at it.
Thanks John. TurboActivate 4.0.5.1 is now out, that fixes this bug.
