haikuwebkit 1.9.0 crashes on DocumentLoader

[madmax]

Only happens in x86 (self build with the size_t coders patch), both with HaikuLauncher and WebPositive, at app start.

[pulkomandy]

There is an alignment problem.

The movapd instruction needs the operand to be aligned to 16 bytes and ESI is not in this report (it is aligned to 8 bytes only).

​https://www.felixcloutier.com/x86/movapd

esi:  0x19820808 // should end in '0' to be a multiple of 16

ESI is loaded from the stack:

mov 0x8(%ebp), %esi

it corresponds to either a local variable or a parameter passed to the function.

[pulkomandy]

It seems WebKit expects system malloc to align everything on 16 bytes since we don't use FastMalloc.

Can you try modifying src/system/libroot/posix/malloc_hoard/heap.h to set ALIGNMENT = 16 in all cases? (it is already set for x86_64 but not for other architectures).

[waddlesplash]

I thought the POSIX specification expects alignment merely to 2 * sizeof(void*), so I don't know if we should make that change, it could lead to a lot of wasted memory for small allocations.

This does not appear to be JIT'ed code, so why is there an SSE instruction here without an alignment check? Does WebKit specify this buffer will be properly aligned? Is there inline assembly being used? GCC is very good about using the proper instructions for buffer alignment...

[madmax]

Tested anyway and got the same error. I also recompiled haikuwebkit, just in case.

ESI points to the DocumentLoader being created. At 0x760 offset (if that's what that means) we have m_loadTiming, which hosts a bunch of MonotonicTime that wraps a double.

[waddlesplash]

I fixed malloc in hrev56613 to use max_align_t properly, however it seems that is usually 8 bytes on 32-bit anyway so it likely won't make any difference here.

Where is the code in question? Are there any extra __attribute__s which might be specifying storage alignment somehow?

[madmax]

No attributes, but I would probably only see them if they were right there in my face.

​m_loadTiming in DocumentLoader. Its type, ​DocumentLoadTiming. ​ResourceLoadTiming (base class of DocumentLoadTiming). ​MonotonicTime (what the Timing things have) and ​GenericTimeMixin, which is the one with the double.

[waddlesplash]

Some of those have macros hanging off them e.g. WTF_MAKE_FAST_ALLOCATED. I glanced at the source for some of them but I didn't see any attributes.

It seems very strange that the DocumentLoader is only aligned on 8 but somehow GCC expects it to be aligned on 16. I suspect the recent disabling of SSE for libwebp is related here, it seems somehow that GCC is making incorrect assumptions about default alignment. Considering max_align_t comes from GCC's own headers, I don't really have any guesses as to how that might have happened.

It should be possible to write some small test applications to prove this is the problem. GCC's compiler specs may be yet again misconfigured.

It would be interesting to see what clang does here. I think GTK WebKit is now built with Clang because it is faster and uses much less memory...

[pulkomandy]

Some of those have macros hanging off them e.g. WTF_MAKE_FAST_ALLOCATED. I glanced at the source for some of them but I didn't see any attributes.

These should do nothing in our case, since we don't enable FastMalloc (which would use bmalloc bundled with WebKit). But it's possible this configuration doesn't get much testing in WebKit.

[waddlesplash]

It appears there is a GCC/Clang difference here. It appears GCC's headers have alignof(max_align_t) come out to be 16 even on 32-bit Linux, while on the same setup Clang gives 8 (according to the Compiler Explorer.) That sounds like a problem waiting to happen!

[3dEyes]

When building webkit-gtk for 32bit I have the same problem. (Error in DocumentLoader). Solved it by building webkit without using system allocator (enabled built-in bmalloc allocator). Works very well with only minor modifications.

[pulkomandy]

I had tried to use bmalloc in haikuwebkit but it will require annotating several classes in Haiku specific code with WTF_MAKE_FAST_ALLOCATED and other macros to get it working. And I also didn't check the impact in terms of performance and memory use.

[pulkomandy]

Trying to build haikuwebkit on my 32bit machine to investigate this over the weekend

[pulkomandy]

Fixed in ​https://review.haiku-os.org/c/haiku/+/5885

[waddlesplash]

Fix merged in hrev56636 +beta4.