Can I make stack overflow warnings fatal?

General Usage
1

I saw my Julia process writing Warning: detected a stack overflow; program state may be corrupted, so further execution might be unreliable. to stderr after failed C-calls. The process is running as a systemd unit. Currently, I’m running a journalctl watcher that kills the Julia process on such rare occasions.

Is there a way to tell the Julia runtime to throw immediately instead of just writing a warning?

I think I’ve mitigated the root cause for the SO — I’m only asking about Julia exiting automatically.

2

I see “fixed on master” here, so this might apply (on second thought it likely doesn’t):

I’m looking into this, but need to run right now, what I found:

3

Thank you, I think the GitHub issue and the fix on master is about a type inference that may cause a stack overflow, not about the SO detection/warning.

The discourse topic you linked is interesting as it throws ERROR: LoadError: StackOverflowError:. I’ve never seen a StackOverflowError and a stacktrace on my workload, there was just the warning I mentioned above, a log message with a huge blob of C pointers, and the program kept running before crashing subsequently.

Obviously, there are some (many?) conditions that can trigger a SO and throwing would be a better fit for a long-running production process.

4

Stack overflows do throw! But it sounds like you’re catching it in a try block. You can make it fatal just by checking the catched exception.

julia> f() = g()
f (generic function with 1 method)

julia> g() = f()
g (generic function with 1 method)

julia> try
           g()
       catch
       end
Warning: detected a stack overflow; program state may be corrupted, so further execution might be unreliable.

julia> try
           g()
       catch ex
           ex isa StackOverflowError && rethrow()
       end
Warning: detected a stack overflow; program state may be corrupted, so further execution might be unreliable.
ERROR: StackOverflowError:
5

That’s it! I have a call to Downloads.request(... throw = false) and a check for Downloads.RequestError only. The warnings I saw originated from the surrounding function. Rethrowing the other error types should fix it.

The stack overflows happened rarely and in a live API only. That made it difficult to track them back to libcurl. Good catch, thank you very much!