[tahoe-dev] [pycryptopp] #34: Segmentation Fault in function X86_SHA256_HashBlocks

[pycryptopp]

#34: Segmentation Fault in function X86_SHA256_HashBlocks
--------------------------+-------------------------------------------------
     Reporter:  francois  |      Owner:          
         Type:  defect    |     Status:  new     
     Priority:  major     |    Version:          
   Resolution:            |   Keywords:  segfault
Launchpad Bug:            |  
--------------------------+-------------------------------------------------

Comment (by warner):

 I observed something similar on a karmic system (in this case the
 linode.com slice to which we're planning to migrate tahoe-lafs.org, the
 host of this here Trac instance). The symptom was a hang in the pycryptopp
 unit tests (and also a hang in the first Tahoe unit test that touched
 pycryptopp). I didn't get a crash, but 'strace' did mention a SIGILL of
 some sort. Running it under GDB didn't seem to reveal anything useful: the
 process hung instead of getting a signal, and interrupting GDB with
 control-C told me that the stack was somewhere in this same
 X86_SHA256_HashBlocks function, but it also gave a lot of "Cannot access
 memory at address .." errors and couldn't show me anything further. The
 last few lines of the Tahoe unit test run's "strace" capture were:

 {{{
 rt_sigaction(SIGILL, {0xb73f5470, [ILL], SA_RESTART}, {SIG_DFL, [], 0}, 8)
 = 0
 rt_sigaction(SIGILL, {SIG_DFL, [ILL], SA_RESTART}, {0xb73f5470, [ILL],
 SA_RESTART}, 8) = 0
 rt_sigaction(SIGILL, {0xb73f5470, [ILL], SA_RESTART}, {SIG_DFL, [ILL],
 SA_RESTART}, 8) = 0
 rt_sigaction(SIGILL, {SIG_DFL, [ILL], SA_RESTART}, {0xb73f5470, [ILL],
 SA_RESTART}, 8) = 0
 rt_sigaction(SIGILL, {0xb73f5440, [ILL], SA_RESTART}, {SIG_DFL, [ILL],
 SA_RESTART}, 8) = 0
 rt_sigaction(SIGILL, {SIG_DFL, [ILL], SA_RESTART}, {0xb73f5440, [ILL],
 SA_RESTART}, 8) = 0
 --- SIGQUIT (Quit) @ 0 (0) ---
 +++ killed by SIGQUIT +++
 }}}


 When I rebuilt pycryptopp with "--disable-embedded-cryptopp", the unit
 tests worked perfectly.

 This was using pycryptopp-0.5.19 . The system's version of libcrypto++8
 was 5.6.0-3 . I don't know what version of Crypto++ is embedded in
 pycryptopp-0.5.19, but the embedded cryptopp/Readme.txt file claims
 "Version 5.6.0 (3/15/2009)".

 My first instinct is to think that something has clobbered the stack, and
 some sort of SIGILL handler has gotten stuck in an infinite loop (maybe a
 C++ exception handler or something?).

-- 
Ticket URL: <http://allmydata.org/trac/pycryptopp/ticket/34#comment:3>
pycryptopp <http://allmydata.org/trac/pycryptopp>
Python bindings for the Crypto++ library