-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Increase the signal stack size on AArch64 #14700
Conversation
The new value (64k) is simply copied from |
With all the work on Aarch64, is there a way to at least test the build regularly? Perhaps we should set up cross compilation on travis? Through qemu we can at least have a couple of simple tests run. Is anyone aware of a service like @scaleway that will provide Aarch64 machines? Scaleway only seems to have 32-bit, although I suspect they should add 64-bit at some point naturally. |
Also use a separate function to unblock the signal in order to save some stack space ( @ViralBShah Maybe http://www.datacentred.co.uk/ ? Not quite the same and more expensive than scaleway if you want to use it all the time (even for the cheapest option). Also couldn't find what hardware they are using. With this patch merged (which somehow mainly causes issue with parallel testing....) the compilation takes ~20min and the whole test suite (with a few tests disabled) takes ~30min to run on my board so it's not too bad for me to run it every night right now. |
3502da0
to
c099808
Compare
The default size is too small for libunwind and causes a stack overflow. Also add a guard page to the signal stack making it easier to detect such problems in the future. (Segfault instead of weird corruption...) [av skip]
This should save some stack space by creating the sigset_t in a separate scope. [av skip]
c099808
to
eb5fa47
Compare
Increase the signal stack size on AArch64
broken on mac?
|
mac uses the other name ( |
The default size is too small for libunwind and causes a stack overflow. (The symptom is error/segfault on exit due to random corruption of heap memory, a lot of the time a segfault in
__cxa_finalize
).Also add a guard page to the signal stack making it easier to detect such problems in the future. (Segfault instead of weird corruption...)
P.S. The default size for linux x86_64 is also quite small (8k), I'm a little surprised that our signal handler works fine in such a shallow stack....
c.c. @vtjnash