Crystal: OverflowError always lead to can't raise END_OF_STACK

[ysbaddaden]

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).

[ysbaddaden]

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"

```Makefile
.POSIX:

all: .phony
bin/crystal build -Dpreview_overflow hello.cr
./hello

.phony:

Direct call: :heavy_check_mark: 
```console
$ bin/crystal run -Dpreview_overflow hello.cr
Using compiled compiler at `.build/crystal'
hello

Indirect call through GNU make: :x:

$ 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): :heavy_check_mark:

$ ./hello
hello

Notice that the program doesn't even reach puts, and is failing somewhere in the prelude.

[ysbaddaden]

I found the culprit for the weird make behavior:
https://github.com/crystal-lang/crystal/blob/master/src/fiber.cr#L106-L108

$ ./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 bottom top of the main thread/fiber stack, and should use other means (non portable pthread calls).

[ysbaddaden]

This is a duplicate a #7368.