On Tue, Apr 29, 2014 at 1:19 PM, Richard Mortimer <ri...@oldelvet.org.uk>wrote:
> Hi, > > > On 29/04/2014 17:26, Colin Watson wrote: > > Program received signal SIGBUS, Bus error. >> 0x003d8c2c in md5_do_chunk () >> (gdb) bt >> #0 0x003d8c2c in md5_do_chunk () >> #1 0x003d9a10 in md5_update () >> #2 0x003d2070 in saqF_ret () >> #3 0x00da1e48 in StgRun () >> #4 0x00d9f65c in scheduleWaitThread () >> #5 0x00d9c774 in real_main () >> #6 0x00d9c8c8 in hs_main () >> #7 0x0003b624 in main () >> (gdb) disas /rm >> Dump of assembler code for function md5_do_chunk: >> 0x003d8c18 <+0>: 9d e3 bf 20 save %sp, -224, %sp >> 0x003d8c1c <+4>: b6 07 bf c0 add %fp, -64, %i3 >> 0x003d8c20 <+8>: 07 00 00 3f sethi %hi(0xfc00), %g3 >> 0x003d8c24 <+12>: 82 10 20 00 clr %g1 >> 0x003d8c28 <+16>: 86 10 e3 00 or %g3, 0x300, %g3 >> => 0x003d8c2c <+20>: c4 06 40 01 ld [ %i1 + %g1 ], %g2 >> > That is loading the 2nd parameter to md5_do_chunk. I think that is defined > as uint32_t *buf > (source http://hackage.haskell.org/package/cryptohash-0.4/src/cbits/md5.c) > > The register dump below shows that %i1 is not 4 byte aligned. > > That would correspond to the force cast of ctx->buf to a uint32_t * > in md5_update in the same file. > As I've mentioned, I've already reported the issue to upstream [1]. Additionally, now I have provided a pull request [2] to resolve the issue. [1] https://github.com/vincenthz/hs-cryptohash/issues/24 [2] https://github.com/vincenthz/hs-cryptohash/pull/25
