I've implemented a patch to used the aligned version in hash_map.h on sparc and it is attached. However, I'm looking at the 64bit version (in build_log.cc) and don't see an aligned version on the murmur page, so any pointers would be helpful.
The patch is against the 1.1.0 source that I'm nearly done patching. Just trying to finish off this bug. If necessary, I can push my current work to mentors or something for further testing. Thanks, -- Gary Kramlich <g...@reaperworld.com> On Sat, Jan 5, 2013 at 12:21 AM, Mathieu Malaterre <ma...@debian.org> wrote: > FYI: > http://lists.debian.org/debian-sparc/2013/01/msg00001.html > > > ---------- Forwarded message ---------- > > > On Sat, Dec 29, 2012 at 03:39:10PM +0100, Mathieu Malaterre wrote: > > Dear sparc gurus, > > > > I am currently starring at: > > > > > https://buildd.debian.org/status/fetch.php?pkg=ninja-build&arch=sparc&ver=1.0.0-2&stamp=1355239881 > > > > This is extremely hard to deduce the type of error ninja-build could > > be doing, that does not please a sparc system. I tried getting access > > to a porterbox sparc machine, but my mail request does not seems to > > reach anything [1], I suspect something is going on wrong ATM. > > > > So could someone with time & expertise could try building > > ninja-build on sparc, and simply executing the test suite ? > > > > Thanks much in advance, > > > > Happy holidays ! > > It crashes in MurmurHash2 code in src/hash_map.h. Here's a backtrace: > > Program received signal SIGBUS, Bus error. > MurmurHash2 (len=12, key=0x4144b) at src/hash_map.h:29 > 29 unsigned int k = *(unsigned int *)data; > (gdb) bt > #0 MurmurHash2 (len=12, key=0x4144b) at src/hash_map.h:29 > #1 operator() (key=..., this=<optimized out>) at src/hash_map.h:89 > #2 _M_bkt_num_key (__n=193, __key=..., this=0x40020) at > /usr/include/c++/4.6/backward/hashtable.h:592 > #3 _M_bkt_num_key (this=0x40020, __key=...) at > /usr/include/c++/4.6/backward/hashtable.h:584 > #4 find (__key=..., this=0x40020) at > /usr/include/c++/4.6/backward/hashtable.h:507 > #5 find (__key=..., this=0x40020) at /usr/include/c++/4.6/ext/hash_map:214 > #6 State::LookupNode (this=0x40020, path=...) at src/state.cc:62 > #7 0x00024fe4 in State::GetNode (this=0x40020, path=...) at > src/state.cc:52 > #8 0x0001ebcc in DependencyScan::LoadDepFile (this=0xffffd5e4, > edge=0x47490, err=0xffffd6cc) at src/graph.cc:312 > #9 0x0001f1f4 in DependencyScan::RecomputeDirty (this=0xffffd5e4, > edge=<optimized out>, err=0xffffd6cc) at src/graph.cc:40 > #10 0x0001f380 in DependencyScan::RecomputeDirty (this=0xffffd5e4, > edge=0x470e8, err=0xffffd6cc) at src/graph.cc:55 > #11 0x0001f380 in DependencyScan::RecomputeDirty (this=0xffffd5e4, > edge=0x4bb70, err=0xffffd6cc) at src/graph.cc:55 > #12 0x00017d90 in Builder::AddTarget (this=0xffffd598, node=0x4bba0, > err=0xffffd6cc) at src/build.cc:612 > #13 0x000136f4 in RunBuild (argv=0xffffd7c8, argc=1, > builder=0xffffd598) at src/ninja.cc:667 > #14 (anonymous namespace)::NinjaMain (argc=1, argv=0xffffd7c8) at > src/ninja.cc:859 > #15 0xf7c44e54 in __libc_start_main () from /lib/sparc-linux-gnu/libc.so.6 > #16 0x00011b98 in _start () > > As you can see, 'key' argument points to unaligned memory location > (0x4144b) and an attempt is made to read an unsigned int from this > location. On sparc any such read will result in process termination if > the memory location is not aligned on a 4-byte boundary. > > It appears that this is a known limitation of original MurmurHash2, > and the author provides a (slower) version which only does aligned > reads: > > > https://sites.google.com/site/murmurhash/MurmurHashAligned2.cpp?attredirects=0 > > This version should work in this case. The implementation of 64-bit > version of the hash used elsewhere in the code should probably be > replaced by an aligned-reads-only version as well. > > Best regards, > -- > Jurij Smakov ju...@wooyd.org > Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC >
murmur2_aligned.patch
Description: Binary data
