New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
StackInfo issues on Alpine (musl-based) #16681
Comments
that error is due to some internal stuff in the (musl) headers- it'll always fail with -Wsign-compare for the cmsg socket stuff. you'll have to get rid of werror like always to run those, but the actual warning doesn't apply there |
(for reference https://www.openwall.com/lists/musl/2016/10/11/1 . but you already knew to nuke Werror :) ) |
i remember trying to debug this some time ago (months), and now, and it's not merely a stack size issue- raising the stacksize via the PT_GNU_STACK elf header (which musl understands) or using the pthread_attr_setstack api does not resolve it. the issue is in the actual calculation done in stackinfo (and if you simply comment it all out and make it say there is always space, the javascript pages work (as a quick test only, of course).). i couldn't figure out /why/ it fails at calculating the remaining stack size on musl libc specifically, and sadly lost any notes i had at the time. |
The implementation for musl glibc is vastly more complex and involves reading |
That's quite unfortunate that we can't calculate "how much stack is left" on musl the same way we do pretty much every other C library (except Wasm32 on emscripten). Looking at your rust link it looks like the answer is "🤷♀️ lmao hope we don't overflow"? Or is there something other language runtimes that we can |
I also looked at Python which is known to be very portable and handles stack overflow - they elaborately hardcode a recursion limit 🤦 I'm unsure if Rust deals with this safely on musl in some other way. (reason why I'm suddenly here: https://donotsta.re/notice/AhnJDfkoKr4E3Fg4oK) |
Wait I've got it. On musl, we should change LibMain to just call serenity_main in a secondary thread and then block the main thread waiting for it to exit! Genius. |
not sure if applicable here, but WebKit does some mildly cursed stuff for calculating the stack size on the main thread: https://github.com/WebKit/WebKit/blob/b64c3ed8059502609a5dba0c79c6d84773362c4a/Source/WTF/wtf/StackBounds.cpp#L139 |
Well... pulling from getrlimit(RLIMIT_STACK) and comparing that to some magic "origin" value doesn't seem like the worst idea. The commit message responsible for that part of wtf mentions that they do something similar on Darwin. |
A patch to add a little extra spice to our ifdef soup in StackInfo.cpp along the lines of
would work for me, if some musl users can confirm it works (and passes test-js, our LibWeb tests, etc). I believe we have at least one test that relies on hitting the stack limits to work. The self-proxy one at least, that one broke when Andreas made ThrowCompletionOr small enough to get things optimized by gcc-13 :thousandyakstare: |
might take a while, there's still some random build failures ( e.g. #21709 was closed with no successor 😔 ) edit: ...and segfaults in |
re: request server, try this: |
funnily enough, i stashed the stack size fix and forgot to reapply it before building, but it.. looks like it works without it(?) i'm still getting some funny errors though, like:
|
nevermind, it might simply be better than it was before, but searching anything in duckduckgo finally makes it trip with |
i tried doing something similar to what WebKit does, but it seems to now go the opposite way and assume the stack is bigger than it actually is:
|
continuing from SerenityOS/ladybird#153 (comment):
@ADKaster Correct, I've tried running it on multiple machines and all of them had the same issue.
I tried running the tests myself on 379e4a2 (HEAD of master at the moment of posting) and they fail with the following:
The text was updated successfully, but these errors were encountered: