(heavily paraphrasing) > [the core dump is supposed to be in the CWD, and named core, but isn't; what gives?] Followed by, $ find / -name core -type f Is

(heavily paraphrasing) > [the core dump is supposed to be in the CWD, and named core, but isn't; what gives?] Followed by, $ find / -name core -type f Is a sort of hilarious brute force solution. But it demonstrates a particular kind of problem, where /-- requires -- evidence | ^ v | answer -- requires -/ These are pesky. The brute force search is a good idea, in that it breaks that cycle of almost needing to know the answer in order to discover it. (Unless you can surmise that the CWD is the crate dir, but let's assume that we don't want to depend on having such a moment of sheet "eureka!".) > But there are also other bits of evidence that this theory doesn’t explain, or even cuts against. (This is what makes post-mortem debugging exciting! There are often contradictory-seeming pieces of information that need to be explained.) I wish more people appreciated this; too many people are apt to sweet such discrepancies under the rug. This post does a good job on not just following through on them, but also showing how figuring some of them out ("why is our stack weird?") leads to the key insights: "oh we're using stacker and … $the_bug". I do wonder how the author managed to notice that line in a 1.5k line stack trace, though. The "abrupt" address change would have probably gone unnoticed by me. (The only saving grace being a.) it's close to the bottom b.) most of the rest is repetitive, an artifact of a recursive descent parser recursing, and if we just consider that repetition "one chunk", it gets a lot smaller. I still dunno if I'd've seen it, though.)