Failed to raise an exception: END_OF_STACK

[KCErb]

Some kinds of dev mistakes can result in the titular error. Usually followed by a pretty nasty looking error message:

Failed to raise an exception: END_OF_STACK
[0x55cae972a076] *CallStack::print_backtrace:Int32 +118
[0x55cae96e3da6] __crystal_raise +86
[0x55cae96e448e] ???
[0x55cae977f6e6] *Crystal::System::File::open<String, String, File::Permissions>:Int32 +214
[0x55cae9776e7f] *File::new<String, String, File::Permissions, Nil, Nil>:File +63
[0x55cae972116d] *CallStack::read_dwarf_sections:(Array(Tuple(UInt64, UInt64, String)) | Nil) +109
[0x55cae9720efd] *CallStack::decode_line_number<UInt64>:Tuple(String, Int32, Int32) +45
[0x55cae97206ae] *CallStack#decode_backtrace:Array(String) +302
[0x55cae9720562] *CallStack#printable_backtrace:Array(String)+ +50
[0x55cae97899fd] *Exception+ +77
[0x55cae9789791] *Exception+ +177
[0x55cae97aaeb8] *AtExitHandlers::run<Int32>:Int32 +488
[0x55cae992377b] *Crystal::main<Int32, Pointer(Pointer(UInt8))>:Int32 +139
[0x55cae96eea26] main +6
[0x7fdf8fe6bb97] __libc_start_main +231
[0x55cae96ded5a] _start +42
[0x0] ???

This feels worse than it is when raised by Heroku because it is all you get back. If you actually run a command on the dyno itself you'll usually get a better idea of what went wrong. The two examples I can give are:

1. Trying to run lucky db.migrate when no DATABASE_URL is set in production. You get this error message before END_OF_STACK

Unhandled exception: dropdb: could not connect to database template1: could not connect to server: Connection refused
    Is the server running on host "localhost" (127.0.0.1) and accepting
    TCP/IP connections on port 5432?
 (Exception)

which is easy to debug

2. When running lucky db.drop which isn't allowed on heroku like so: heroku run lucky db.drop (you're supposed to use their method heroku pg:reset DATABASE).

This time you don't get any message from lucky, I guess it is swallowed by Heroku and then they return the END_OF_STACK error I pasted from above.

Both are database related errors, so perhaps the issue is listening for errors related to db tasks?

[edwardloveall]

I got a similar stack trace when my SEND_GRID_KEY environment variable was missing. We do raise if some of these keys are missing ENV["SEND_GRID_KEY"]? || raise_missing_key_message but maybe it's not working like we expect?

[KCErb]

On the DB-related errors, this might be related: https://github.com/crystal-lang/crystal-db/issues/103. We might need to handle initializing the connection a little differently. Not sure.

[jwoertink]

Might be related: https://github.com/crystal-lang/crystal/issues/8387

[lugia-kun]

That backtrace is same to crystal-lang/crystal#8075.