[Webkit-unassigned] [Bug 225099] [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

--- Comment #7 from Mark Lam <mark.lam at apple.com> ---
(In reply to Daniel Kolesa from comment #4)
> I should probably adjust the comments a bit more to clarify things -
> notably, it's not that musl always returns 128k, it actually calculates the
> currently available size (which happens to be 128k as that's what the
> initial size is at the point; this was confirmed by the musl author, and
> that it's intended behavior)
> 
> so the solutions are really two - either do what i'm doing (but update the
> comment) or pre-poke the stack (which i don't think is necessary - it's fine
> that it grows, it's just that the stack boundary is created once on startup
> and never updated later, so it should represent the maximum rather than
> current)
> 
> anyway, after someone involved with JSC confirms it's fine, I will do a
> final update on the patch along with other potential review changes.

FYI, the StackBounds is expected to be constant.  Client code can cache it to avoid continually probing for the bounds.  One can expect that whatever it returns the first time is the bounds the code will use for the lifecycle of the process.  StackBounds should never lie and claim to have more stack than is actually available.  The downside of doing so is that it will crash when the client use stack memory that isn't actually there.

And yes, adding the details to the ChangeLog will probably be helpful as future readers of this code will be consulting it for the rationale of your implementation.

-- 
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/4440d473/attachment-0001.htm>