(Cc'ing debian-sparc to get some informed opinion from there) On Tue, Jun 24, 2008 at 03:02:38AM +0200, Sune Vuorela wrote: > [cutting a bit from different messages] > > On Tuesday 24 June 2008 01:33:36 Axel Beckert wrote: > > > One note though: Since I found the very same issue also with > > kazehakase-webkit (but not kazehakase-gecko), midori and arora on > > Sparc, the issue maybe somewhere in webkit itself instead of epiphan > > Could very well be. And please note that arora uses qtwebkit which isn't > build > from webkit source package (so probably clone && reassign should be needed) > > > #debian.de suspects some memory alignment bugs which are said to often > > show up first on the quite pedantic Ultra Sparc processors like in my > > Ultra 10. > > > Program received signal SIGBUS, Bus error. > > Isn't sigbus usually related to unaligned accesses ?
I would say so. > > [Switching to Thread 0xf6eba730 (LWP 17762)] > > WTF::TCMalloc_PageHeap::GrowHeap (this=0xf7f68dc4, n=1) at > > ../JavaScriptCore/wtf/FastMalloc.cpp:1466 > > 1466 ../JavaScriptCore/wtf/FastMalloc.cpp: No such file or directory. > > in ../JavaScriptCore/wtf/FastMalloc.cpp > > Current language: auto; currently c++ > > and this is the web template framework, part of webkit, so yeah. > web template framework is at least also in khtml as in kde4, but at least the > FastMalloc part is quite ... different. > http://websvn.kde.org/trunk/KDE/kdelibs/kjs/wtf/FastMalloc.h?revision=809424&view=markup > so khtml probably isn't relevant here. > > but looking at JavaScriptCore/wtf/ ... > > FastMalloc.cpp:1098: uint64_t system_bytes_; > FastMalloc.cpp:1466: uint64_t old_system_bytes = system_bytes_; > > I'm a bit .. puzzled ? It could make sense, if sparc needs this uint64_t to be 64-bit aligned. And it looks like so: (gdb) print $pc $1 = (void (*)(void)) 0xf7e3b880 <WTF::TCMalloc_PageHeap::GrowHeap(unsigned int)+104> (gdb) disassemble $pc $npc Dump of assembler code from 0xf7e3b880 to 0xf7e3b884: 0xf7e3b880 <_ZN3WTF17TCMalloc_PageHeap8GrowHeapEj+104>: ldd [ %i0 + %g2 ], %o4 End of assembler dump. (gdb) info registers i0 g2 i0 0xf7f9cdc4 -134623804 g2 0x50b8 20664 0x50b8 & 7 is 0, but 0xf7f9cdc4 & 7 is not, so i0 + g2 is not 64-bit aligned. If the diagnostic is correct, what would be the best way to fix this ? Split the assignment into 2 uint32_t ones ? Or is there a way to have the class 64-bit aligned ? Or maybe a way to get gcc to split the uint64_t assignment itself ? Cheers, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]