Re: Bug#487745: epiphany-webkit: crashes on startup
(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
> > 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.
> so khtml probably isn't relevant here.
> 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
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 ?