Reproducer: $ ulimit -s unlimited $ jsc >>> 1 + 1 Exception: I'm not sure why JSC cannot print the exception, but it's "maximum call stack size exceeded." Problem is since r276695 "[WPE][GTK] More correct fixes for stack size issues on musl libc", WTF::StackBounds::currentThreadStackBoundsInternal now calls getrlimit() to get the soft stack limit. When the limit is unlimited, rlim_cur is -1 and the function is not prepared for that. I don't know how to fix it other than to fall back to some suitable default (8192 seems to be the default soft limit). This is only a regression on Linux, but the Darwin code has the same bug too.
let's have it max out at 8M, realistically there is nothing better you can do i think
Actually I'm not certain it's really a regression, because there are preexisting calls to pthread_getattr_np() (or pthread_get_stacksize_np() on Darwin) that would likely have had the same problem. (In reply to Daniel Kolesa from comment #1) > let's have it max out at 8M, realistically there is nothing better you can > do i think Sounds good.
(In reply to Michael Catanzaro from comment #0) > When the limit is unlimited, > rlim_cur is -1 and the function is not prepared for that. Actually, it is RLIM_INFINITY. Doesn't change the rest of the analysis, though.
Created attachment 442530 [details] Patch
(In reply to Michael Catanzaro from comment #2) > Actually I'm not certain it's really a regression, because there are > preexisting calls to pthread_getattr_np() (or pthread_get_stacksize_np() on > Darwin) that would likely have had the same problem. I think it's OK because this returns the real stack size, not the limit. Also, it works fine in practice with no changes to this.
patch lgtm
<rdar://problem/84943302>
Ping reviewers
Comment on attachment 442530 [details] Patch r=me
Committed r285187 (243816@main): <https://commits.webkit.org/243816@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 442530 [details].