A quick google result shows this source file is likely where the issue actually exists:
http://hackage.haskell.org/package/cryptohash-0.4/src/cbits/md5.c md5_update() -> md5_do_chunk(). This uses the macro cpu_to_le32_array(), which in turn comes to array_swap32(): static inline void array_swap32(uint32_t *d, uint32_t *s, uint32_t nb) { while (nb--) *d++ = swap32(*s++); } This loads a uint32_t from *s, swaps the byte order, then stores into *d. If either *s or *d are not aligned pointers (i.e. low 2 bits of address are 0), then SPARC will generate a SIGBUS and crash. I would bet money that patching this function will resolve the issue (and probably other issues if this function is used elsewhere). I can write up a patch for it, but I'm not sure how to get it accepted upstream. Patrick On Tue, Apr 29, 2014 at 10:08 AM, Joachim Breitner <[email protected]>wrote: > [Taking a few lists of the CC, no need to spam everyone.] > > Dear Patrick, > > Am Dienstag, den 29.04.2014, 09:41 -0500 schrieb Patrick Baggett: > > > I'd like to look into the TLS failures. Bus errors usually mean > > "misaligned data" which aren't very difficult to fix once you see the > > source code. Is there a bug report for the SPARC failure? Help me > > reproduce it on my local machine and I think I should be able to fix > > it soon! > > that would be great! But note that you might have to dive into the depth > of the Haskell compiler GHC. > > To reproduce, simply try to build haskell-tls. I was able to reproduce > it on the porter machine. > > I filed https://bugs.debian.org/744920 and > https://ghc.haskell.org/trac/ghc/ticket/9002 for them. > > Greetings, > Joachim > > > -- > Joachim "nomeata" Breitner > Debian Developer > [email protected] | ICQ# 74513189 | GPG-Keyid: F0FBF51F > JID: [email protected] | http://people.debian.org/~nomeata > >
