Now with better commits that should be easier to read :)

And now with support for atos on OSX. All targets should now be supported.

I can't figure why CI fails so badly. I can't reproduce any of the errors 😢

It seems a bug in libevent (searched from Google)

@ysbaddaden this is great! Is there any use case for keeping the hexadecimal (address?) at the beginning of the line?

I don't know why it fails, but if I run this snippet of code:

# foo.cr
raise "OH NO!"

$ bin/crystal foo.cr
OH NO! (Exception)
Unhandled exception in spawn:
end of file reached (IO::EOFError)
# hangs there...

So that probably means there's something missing in the implementation.,,

I guess the "open the file then pass addresses as stdin" is quirky, or it should catch some errno. I'll revert to a basic "pass addresses as CLI args".

@mverzilli thats the raw symbols address. It's nit useful to most people, but maybe some would like it, so they hexdump the binary and follow what ASM is doing? I'm not sure.

The problem is actually within Process.run which raises an IO::EOFError whenever I run the addr2line -e PROGRAM_NAME command 😢

@asterite it doesn't hang on Linux, but crashes in SignalHandler while receiving the SIGCHLD signal, because @write_pipe is closed (I was capable to find this thanks to addr2line). If I comment the line 67 then it hangs after the IO::EOFError with no backtrace.

I found the issue and it lies in Event::SignalHandler. The pipes are closed before receiving the SIGCHLD signal (which raises the IO::EOFError and sometimes IO::Error exceptions in fibers, hence the Unhandled exceptions message). The signal is never reported back to Process so Process#wait hangs forever...

Dropping the at_exit { Event::SignalHandler.close } in src/kernel.cr fixes the issue, but I have no idea why the code was here I the first place since the pipe would be closed anyway when the process actually exits.

I wonder, thought, why the at_exit handlers are run before the exception is printed?

Closed in favor of #3303.