A git grep 'exit(' in runtime shows there are a few other places in the runtime system where it exit(2). I think at least one of these can safely be turned into caml_fatal_error: it's the first hit in win32.c. I'm unclear about those in fail_{byt,nat}.c.

The other ones and those calling caml_sys_exit are more tricky since they also involve Stdlib.at_exit handlers which you might not expect to run before an abort(). In particular changing the default behaviour in case of uncaught exception in printexc.c might not be a great idea and this one the user program can at least prevent it from happening and messing with its own exit usage.

Well spotted! I turned calls to exit(2) in fail_xxx.c and win32.c into fatal errors. I also fixed one typo and removed spurious calls to exit(-1) in the debugger.

I think this is a good idea: when the OCaml runtime fails, it is better to abort() than to exit with an error code.

However, caml_fatal_error is also used in the bytecode runtime for several more boring errors (e.g. if you run ocamlrun file_that_does_not_exist, you get a fatal error). I don't think these situations should trigger a SIGABRT.

I think the right thing to do here is to have caml_fatal_error call abort, but call exit(N) instead in these situations in runtime/startup_byt.c. I'm not sure what the exit code should be: ocaml currently exits with 2, but I think 127 is a more normal code for when an executable file cannot be found.

I think this is a good idea: when the OCaml runtime fails, it is better to abort() than to exit with an error code.

However, caml_fatal_error is also used in the bytecode runtime for several more boring errors (e.g. if you run ocamlrun file_that_does_not_exist, you get a fatal error). I don't think these situations should trigger a SIGABRT.

I think the right thing to do here is to have caml_fatal_error call abort, but call exit(N) instead in these situations in runtime/startup_byt.c. I'm not sure what the exit code should be: ocaml currently exits with 2, but I think 127 is a more normal code for when an executable file cannot be found.

Done.

Another instance, detailed below, is when the C code tries to raise an OCaml exception and the OCaml code isn't initialized yet. This case was carefully reported like an uncaught exception, and you turned it into an abort(). This is debatable.

As I explained, I think it should be considered UB to call OCaml runtime functions if said runtime is not initialized. Most of the external functions of the OCaml runtime requires it to be initialized anyway (allocation...). I think the test in check_global_data is only there because intern can raise an exception while decoding the bytecode executable.

If you don't agree, then I'll be happy to go back to the previous version (which is just a little less factorized). I just need to know what you think to move forward :)

I'm OK with the general idea: an internal error in the runtime system should abort() rather than exit(2).

ftr now I strongly support @dbuenzli idea of overridable C handler for this kind of unexpected situations. E.g. in our usecase we want to output log in some specific format so that our monitoring tools can track this situation same way as all other logs. Also from practice - we may not always want to do a coredump on oom (this contradicts what I said before, but that's what practice taught me - consuming all IO of a rood disk to get a 200G coredump is not always desirable).

The size of core dumps is not a factor here: just use ulimit -c N to limit the max size of core dumps, or ulimit -c 0 to make sure that core dumps are never generated.

This said, I am sympathetic to the idea that users could provide their own handler function instead of the default abort().

ftr now I strongly support @dbuenzli idea of overridable C handler for this kind of unexpected situations.

Isn't it possible to install a signal handler for SIGABRT?

As I explained, I think it should be considered UB to call OCaml runtime functions if said runtime is not initialized.

This is a reasonable claim that is open for discussion. I still think you need to know why the code you're modifying is written the way it is written, and be aware of what you are changing, rather than changing it without understanding it.

The size of core dumps is not a factor here: just use ulimit -c N to limit the max size of core dumps, or ulimit -c 0 to make sure that core dumps are never generated.

We still want to get (full) coredumps for real segfaults..

Isn't it possible to install a signal handler for SIGABRT?

maybe, but I think explicit handler is better mechanism

Isn't it possible to install a signal handler for SIGABRT?

In the handler the context is lost, is the abort coming from OCaml or from C ? If my main is in C I may simply choose to shutdown the OCaml system and restart it.

I think it's a good idea if the OCaml runtime strives to be treated as C library. In other words that it tries as much as possible not to fiddle with the non compositional aspects of the C runtime/standard library.

@xavierleroy : alright, I restored the initial code for the three changes you mentioned.

@dbuenzli , @ygrek : your wish is granted. caml_fatal_error now calls caml_fatal_error_hook if not NULL. Note, however, that this hook is not called in case of unhandled exception or failed startup.

Do I understand correctly that the hook mechanism answers @ygrek's concerns about core dumps? Or is there still a problem with standalone applications?

I rebased, squashed the commits, and mentionned the new hook in Chances. @xavierleroy : if this looks good to you , then this should be ready to merge.

@xavierleroy: you approved these changes one 1.5 months ago. Is there anything blocking the merge?

I guess I was hoping someone else would bother to merge :-)

Let's merge, then.