Most of these bug reports claim that this might be related to the default stack size for new threads in musl. Which is a lot smaller than the default stack size in glibc (see: https://wiki.musl-libc.org/functional-differences-from-glibc.html#Thread-stack-size)
I compiled the attached code snippet with `gcc -o test test.c $(pkg-config --cflags webkit2gtk-4.0) $(pkg-config --libs webkit2gtk-4.0)` on Alpine Linux Edge (x86_64) using webkit 2.20.3. Invoking the resulting binary produces the following output: `test: JSEvaluateScript failed`.
I also invoked the binary with valgrind (the output can be found here https://paste42.de/13254/) which makes me believe that this is really an issue regarding the thread stack size since various attempts are made to access memory below the stack pointer. Besides the test program segfaults when started with valgrind which is also strange.
I (and the people who created the bugs linked above) would be very happy if this could be investigated further and (hopefully) be fixed soon. I would also suggest that you run your test suite on a musl-based system as well to prevent these kind of issues in the future.
Created attachment 344619 [details]
Minimal test program to reproduce the issue
Created attachment 344620 [details]
Valgrind output for the test program
Yeah, this is because musl's stack size is very small.
So, all the stack overflow checks fail since soft stack limit is smaller than the current stack pointer.
We can make JSC work by changing MinimumReservedZoneSize.h from `static const unsigned minimumReservedZoneSize = 16 * KB;` to `static const unsigned minimumReservedZoneSize = 4 * KB;` or smaller value (At least in my Linux box using glibc, with `ulimit -s 80`).
But it seems dangerous to me. Personally, I think increasing the default stack size of musl is the right way to fix.
When setting `ulimit -s 100` in my Linux box (using glibc), even gdb fails to start.
The difficult thing is that we cannot deploy this tweak for musl, since musl does not provide any macro / definition to detect musl intentionally, while musl's behavior is different from glibc (actually stack size is small) :(.
Mark, what do you think of?
Unfourtunatly, simply increasing the stack size is not enough. The following patch is currently used by Alpine Linux and Void Linux for their webkit2gtk package: https://git.alpinelinux.org/cgit/aports/tree/community/webkit2gtk/musl-fixes.patch?id=609fbb0235cf6440f5d502885c4e0531c835aed7
One way which seems less hacky/faulty than the alpine patch there would be to use pthread_attr_setstacksize like musl suggests (and no #ifdef should be required as it is POSIX) and/or "increasing the default stack size via the PT_GNU_STACK program header, which can be set at link time via -Wl,-z,stack-size=N".
I don't have much compiling power on my musl machine now (~2012 laptop with intel vulns, will replace it) but I'll try the latter.
(In reply to Haelwenn (lanodan) Monnier from comment #5)
> One way which seems less hacky/faulty than the alpine patch there would be
> to use pthread_attr_setstacksize like musl suggests (and no #ifdef should be
> required as it is POSIX) and/or "increasing the default stack size via the
> PT_GNU_STACK program header, which can be set at link time via
> I don't have much compiling power on my musl machine now (~2012 laptop with
> intel vulns, will replace it) but I'll try the latter.
The patch in bug #208223 adds configuring stack sizes, so once that
lands maybe the only leftover thing to do in this regard is to detect
if Musl is being used (tricky, maybe it's better to check for “not
glibc”) and set some sane value for DEFAULT_THREAD_STACK_SIZE_IN_KB.
Thank you guys for looking into this :)
I'd very much like to use a WebKit browser on a musl system (Alpine Linux).
(In reply to Adrian Perez from comment #6)
> The patch in bug #208223 adds configuring stack sizes, so once that
> lands maybe the only leftover thing to do in this regard is to detect
> if Musl is being used (tricky, maybe it's better to check for “not
> glibc”) and set some sane value for DEFAULT_THREAD_STACK_SIZE_IN_KB.
Now that bug 208223 is resolved, is detecting mucl the only thing left to do?
For what my razor-thin understanding is worth, musl is a strict C library compared to the GNU C library with its own additions? If this is the case, could the condition case not be reversed, i.e. if GNU C additions are available, target those, otherwise, target strict C?
JSC is working fine after the patch for bug #210068 landed,
so let's close this :)
*** This bug has been marked as a duplicate of bug 210068 ***