[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 #8 from Daniel Kolesa <dkolesa at igalia.com> ---
> 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.

well, that's the assumption we're working with in this patch - for main thread, it's initialized once, to the size the stack can have at maximum

on glibc and most other libc's, pthread_attr_getstack will already return the maximum, while on musl, it returns the current size (it will automatically grow though, unlike thread stacks which never grow further)

> I see this set of conditionals used in more than 1 place (3 in this patch). 
> Would it be better to define USE_MUSL in PlatformUse.h and check #if
> USE(MUSL) here (and in the other places)?  Is this code only needed for musl?

that's the thing - it's technically not needed on glibc/bionic (since the pthread api already returns what we expect), but if we also enabled it for glibc/bionic, it wouldn't hurt anything

which is why i'd perhaps like to change the conditional to just '#if OS(LINUX)' and use it everywhere, to avoid needless platform checks

that conditional will obviously catch other libc's than musl as well; there's no telling what kind of behavior they will actually have - so we should play it safe for those either way

musl has no test macro of its own, intentionally (in order to encourage people to write portable code)

-- 
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/0c878d21/attachment.htm>