Bug#487745: epiphany-webkit: crashes on startup

[Mike Hommey]

(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