[tahoe-dev] [pycryptopp] #24: SHA256 failure on NetBSD with multiple segments

[pycryptopp]

#24: SHA256 failure on NetBSD with multiple segments
----------------------+-----------------------------------------------------
Reporter:  warner     |           Owner:  bdew 
    Type:  defect     |          Status:  new  
Priority:  critical   |         Version:  0.5.1
Keywords:  integrity  |   Launchpad_bug:       
----------------------+-----------------------------------------------------

Comment(by bdew):

 Huh?.. iv'e tried running it under valgrind and it shows an invalid
 instruction error:

 {{{
 ==10192== valgrind: Unrecognised instruction at address 0x5c33c8e.
 ==10192== Your program just tried to execute an instruction that Valgrind
 ==10192== did not recognise.  There are two possible reasons for this.
 ==10192== 1. Your program has a bug and erroneously jumped to a non-code
 ==10192==    location.  If you are running Memcheck and you just saw a
 ==10192==    warning about a bad jump, it's probably your program's fault.
 ==10192== 2. The instruction is legitimate but Valgrind doesn't handle it,
 ==10192==    i.e. it's Valgrind's fault.  If you think this is the case or
 ==10192==    you are not sure, please let us know and we'll try to fix it.
 ==10192== Either way, Valgrind will now raise a SIGILL signal which will
 ==10192== probably kill your program.
 ==10192==
 ==10192== Process terminating with default action of signal 4 (SIGILL)
 ==10192==  Illegal opcode at address 0x5C33C8E
 ==10192==    at 0x5C33C8E: CryptoPP::SHA256::HashMultipleBlocks(unsigned
 int const*, unsigned int) (sha.cpp:434)
 ==10192==    by 0x5C048D6: CryptoPP::IteratedHashBase<unsigned int,
 CryptoPP::HashTransformation>::Update(unsigned char const*, unsigned int)
 (iterhash.cpp:55)
 ==10192==    by 0x5C3A94E: SHA256_update(SHA256*, _object*)
 (sha256module.cpp:49)
 ==10192==    by 0x80CE880: PyEval_EvalFrameEx (ceval.c:3600)
 ==10192==    by 0x80CF89C: PyEval_EvalFrameEx (ceval.c:3698)
 ==10192==    by 0x80D00C4: PyEval_EvalCodeEx (ceval.c:2875)
 ==10192==    by 0x8116C7D: function_call (funcobject.c:517)
 ==10192==    by 0x805D4B6: PyObject_Call (abstract.c:1861)
 ==10192==    by 0x80CD5B9: PyEval_EvalFrameEx (ceval.c:3892)
 ==10192==    by 0x80D00C4: PyEval_EvalCodeEx (ceval.c:2875)
 ==10192==    by 0x8116B90: function_call (funcobject.c:517)
 ==10192==    by 0x805D4B6: PyObject_Call (abstract.c:1861)
 ==10192==
 ==10192== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2190 from
 9)
 ==10192== malloc/free: in use at exit: 9,068,451 bytes in 13,510 blocks.
 ==10192== malloc/free: 279,589 allocs, 266,079 frees, 66,658,102 bytes
 allocated.
 ==10192== For counts of detected errors, rerun with: -v
 ==10192== searching for pointers to 13,510 not-freed blocks.
 ==10192== checked 9,053,816 bytes.
 ==10192==
 ==10192== LEAK SUMMARY:
 ==10192==    definitely lost: 0 bytes in 0 blocks.
 ==10192==      possibly lost: 156,820 bytes in 425 blocks.
 ==10192==    still reachable: 8,911,631 bytes in 13,085 blocks.
 ==10192==         suppressed: 0 bytes in 0 blocks.
 }}}

 Without valgrind it runs and fails the tests... no crash.

 Regarding possible hardware problems - I'll check more into it, never saw
 gcc crashes on it before, but this computer is pretty old and could
 develop some hardware problems. Also it doesn't have ECC on memory so it
 could just be some cosmic particle flying around deciding to flip some bit
 ;)

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