-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
OverflowError always lead to can't raise END_OF_STACK #7369
Comments
Trying to debug this, I noticed a very weird behavior: the build program will crash with an OverflowError when run from make, but will succeed when called outside of make: # hello.cr
puts "hello" .POSIX:
all: .phony
bin/crystal build -Dpreview_overflow hello.cr
./hello
.phony: Direct call: ✔️ $ bin/crystal run -Dpreview_overflow hello.cr
Using compiled compiler at `.build/crystal'
hello Indirect call through GNU make: ❌ $ make
bin/crystal build -Dpreview_overflow hello.cr
Using compiled compiler at `.build/crystal'
./hello
Unhandled exception: Overflow (OverflowError)
Failed to raise an exception: END_OF_STACK Direct call of built binary (that crashed through make): ✔️ $ ./hello
hello Notice that the program doesn't even reach |
I found the culprit for the weird make behavior: $ ./hello
stack_size = rlim.rlim_cur # => 8388608_u64
@stack_bottom.address # => 140726095376384_u64
$ make
rlim.rlim_cur # => 18446744073709551615_u64
@stack_bottom.address # => 140737488347136_u64 We thus can't use the soft limit of RLIMIT_STACK to detect the stack |
This is a duplicate a #7368. |
Using `getrlimit` led to invalid STACK SIZE limits in some cases which in turn led to an integer overflow while detecting the stack base of the main stack. This patch replaces `getrlimit` with proper, but non portable, calls to pthread functions that return the stack of a given thread. fixes crystal-lang#7368 fixes crystal-lang#7369
Using `getrlimit` led to invalid STACK SIZE limits in some cases which in turn led to an integer overflow while detecting the stack base of the main stack. This patch replaces `getrlimit` with proper, but non portable, calls to pthread functions that return the stack of a given thread. fixes crystal-lang#7368 fixes crystal-lang#7369
Using `getrlimit` led to invalid STACK SIZE limits in some cases which in turn led to an integer overflow while detecting the stack base of the main stack. This patch replaces `getrlimit` with proper, but non portable, calls to pthread functions that return the stack of a given thread. fixes crystal-lang#7368 fixes crystal-lang#7369
Using `getrlimit` led to invalid STACK SIZE limits in some cases which in turn led to an integer overflow while detecting the stack base of the main stack. This patch replaces `getrlimit` with proper, but non portable, calls to pthread functions that return the stack of a given thread. fixes #7368 fixes #7369
Using `getrlimit` led to invalid STACK SIZE limits in some cases which in turn led to an integer overflow while detecting the stack base of the main stack. This patch replaces `getrlimit` with proper, but non portable, calls to pthread functions that return the stack of a given thread. fixes #7368 fixes #7369
Happens systematically on Ubuntu 14.04 / x86_64-linux-gnu for me.
It seems Debug::ELF and/or Debug::DWARF are trying to raise an exception but fail to —because we're already inside an exception handler?
Yet, compiling with
--no-debug
has no impact (it still raises an OverflowError).The text was updated successfully, but these errors were encountered: