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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
