[Webkit-unassigned] [Bug 225099] New: [WPE][GTK] More correct fixes for stack size issues on musl libc

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=225099

            Bug ID: 225099
           Summary: [WPE][GTK] More correct fixes for stack size issues on
                    musl libc
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Template Framework
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: dkolesa at igalia.com

[WPE][GTK] More correct fixes for stack size issues on musl libc

Partial revert https://bugs.webkit.org/show_bug.cgi?id=210068

While the changes in r236306 stopped JSC from crashing outright, they are not correct, since they also make it rather unstable.

To counter this, increase stack size for threads on musl to 1M, to match other systems but not be overly greedy like e.g. glibc.

While at it, the previous approach to musl thread stack size was breaking use of DEFAULT_THREAD_STACK_SIZE_IN_KB (if defined) as well as not properly taking care of the unused parameter. Move the code to a more appropriate place, which solves these problems.

All this is however not enough, since there is still the main thread; on musl, attempting to get the stack size of main thread via the API provided by pthreads results in the value of 128k, which is the reserved kernel size. WebKit then uses this to check the stack size of all threads, including main. That results in small stack bounds for the main thread, which results in JSC thinking it has overflown the stack, and crashes many websites.

In order to fix this, we need to do something similar to what is already being done for Drawin - use the resource limits interface for main thread instead.

Finally, drop the special casing in JSC options. It is no longer necessary - softReservedZoneSize was causing a crash at a value of 128K because of the main thread stack bounds, and this is now anon-issue. We can keep the maxPerThreadStackUsage at 5M as well; there is no fundamental difference from how things are done on glibc anymore.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210427/2fceadb7/attachment-0001.htm>