On Thu, Mar 28, 2013 at 6:48 AM, Jeffrey Walton <[email protected]> wrote:
> Hi Brian, > > On Mar 7, 2:41 am, Brian Vincent <[email protected]> wrote: > > I'm using CryptoPP's AES-256 encryption. It's working for 99% of people > > just fine. So far, 2 separate people are experiencing segfaults. The > seg > > fault seems to happen after successfully encrypting thousands of blocks, > so > > even on their machines, it doesn't always fail. > > > > Program terminated with signal 11, Segmentation fault. > > #0 CryptoPP::Rijndael::Enc::AdvancedProcessBlocks (this=Cannot access > > memory at address 0x8 > > ) at rijndael.cpp:1233 > > 1233 return length % BLOCKSIZE; > > (gdb) > > > > (gdb) bt > > #0 CryptoPP::Rijndael::Enc::AdvancedProcessBlocks (this=Cannot access > > memory at address 0x8 > From this output, it looks like ECX (the 'this' pointer) is getting > blown away. I'm not sure what's at +8, but I'm not sure it matters > either. Finding that overwrite seems to be very relevant, though :) > I thought this this was due to the ebp register being 0. I think the saved eip register is saved at ebp+0x4, and the first arguments on the stack are saved at ebp+0x8. So I think that error is when gdb is trying to look at the first argument, this. > > > ) at rijndael.cpp:1233 > > Cannot access memory at address 0x4 > > > > (gdb) info registers > > eax 0x7639370 123966320 > > ecx 0x0 0 > > edx 0xac64 44132 > > ebx 0x0 0 > > esp 0x76391f0 0x76391f0 > > ebp 0x0 0x0 > > esi 0x64 100 > > edi 0x8643434e -2042412210 > > eip 0x83d45e8 0x83d45e8 > > ... > > > 1. Interestingly, valgrind will report an error on the exact same > assembly > > instruction, when attempting to access "length", saying that it's > > uninitialized. > > 2. Valgrind will report that error, even when "length" is perfectly > > initialized, supporting the claim that it really is a false-positive. > Its interesting things look right in the sources, but Valgrind flags > it during dynamic analysis. > > Perhaps its a GCC or BinUtils problem? Have you tried another version > of the tools? > Nope. > > > Can anyone help? > Is AdvancedProcessBlocks using ECX? Is it preserving it (push/pop)? I > expect so, but it does not hurt to ask. > At the beginning of the asm function, the ecx is a pointer to "locals". But the asm function uses ecx, so it might be fine that it's 0 at this point. I have trouble following the aes code in assembly. > > I assume the problem goes away when defining CRYPTOPP_DISABLE_ASM. > I would assume so too. The crashes that people are getting with our program only happen when they take this SSE2 assembly code path, and not the c codepath or the AESNI code path. > > Jeff > > -- > -- > 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 a topic in the > Google Groups "Crypto++ Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/cryptopp-users/qGIdqp3MIgg/unsubscribe?hl=en > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- 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 Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
