difference from setting panic = abort?

[davepacheco]

Thanks for this crate! Can you explain the difference between using this crate and setting panic = abort (also documented in Cargo)?

[d-e-s-o]

There are two things. First off, while aborting (using panic = abort) is (likely to be?) issuing SIGABRT which is said to create a core dump as part of its default action, that may not happen for other reasons. See core(5) for a list of necessary preconditions. On most systems that I have seen (that may or may not be a representative set), core dumps are disabled by default by virtue of their max size being set to zero. As such, no core dump may be created even if you have this setting in your Cargo.toml.
coredump changes this limit (to the degree that is not prevented altogether by the system (again, core(5) has the glory details).

Second, a setting such as panic = abort really would only create a core dump as one side effect. The other side effects may or may not be desired. What if you want to catch a certain panic in the code? Or you do want meaningful backtraces printed? Well, guess you can't have everything.
So really what you'd want is a separate way to control whether a core dump is created that does not influence unrelated variables. And that's what the coredump crate provides you with, because you can decide when to use it.

[davepacheco]

Thanks for that explanation! The ulimit configuration makes sense. I wanted to better understand your point about side effects, so I wrote a bunch of tests to see what happens with panic = abort vs. enabling this crate. I found that in both cases, you always get a pretty stack trace, and a panic cannot be caught (at least, not with catch_unwind). That said, an advantage of using this crate is that you can get core dumps from integration tests. For a lot more detail, here are the tests I ran. I didn't automate the data analysis -- it's possible I've got something wrong here, but I double-checked the output from the case where we enable "coredump" and we definitely try to catch the panic but dump core (and terminate) before doing so.

[d-e-s-o]

Good point. Yes, my example was badly chosen, because we get a core dump by sending a signal which in turn will terminate the program. So you can't catch panics either. But that's not a true necessity: like gcore we could create a core dump for a running program and could still bubble up the panic. Of course, that would be horrible for other reasons because core dumps typically are not exactly small and chances are there are a lot of panic when you intentionally rely on catching panics. In any case, I'd say the larger point stands.