5

If a macOS application crashes, CrashReporter will (optionally) pop up a window with a human-readable set of stack traces and the "Send to Apple" button.

Is there a straightforward way to get the same results for a non-.app program which crashes when started from the command line? That is, the situation I want more information out of is

$ some-program
Segmentation fault: 11
$

I've only found instructions about how to enable core dumps, but not how to get something readable out of them. I know that Activity Monitor can "sample" running programs, but I'm looking for the crash event, not profiling.

I've thought of creating a dummy .app package that actually runs the command that's crashing, but that'll be a bit of work and probably run into some Gatekeeper trouble, though I haven't actually tried doing that since a few major versions ago. I'm currently on Catalina 10.15.7.

Improve this question

1 Answer 1

Reset to default
2

Looking back, past crashes are logged in the log system, and also individual dump files are saved for about a month in /Library/Logs/DiagnosticReports

Looking forward, to cause them is a bit harder and risky. You could try issuing a SIGABRT or SIGQUIT signal if you know the process:

Something more generic would be the general system diagnostics will capture much more. The main difference in these two options is a crash has an end point, system diagnosis grabs an arbitrary snapshot, so it isn’t necessarily as final as a crash. I don’t recommend forcing an app to crash and certainly don’t recommend forcing a kernel panic but you could try both. Why not start with a general diagnostic dump:

sudo sysdiagnose

You can pass a process ID or process name to sysdiagnose or also trigger it from the Activity Monitor app.

If you need to halt the program or process, try Instruments from Xcode.

Improve this answer
4
  • In hindsight I didn't quite make it clear enough: I'm not trying to get info from a running program, but one that did crash, so "how to crash", Activity Monitor and Instruments are all not relevant. I've edited my question to make the focus clear. • However, I see that sysdiagnose did in fact produce .crash files for the commands I wanted to troubleshoot. Do you happen to know if there is a way to get these files that's faster than running the fairly slow sysdiagnose command and unarchiving its output?
    – Kevin Reid
    Commented Nov 18, 2020 at 1:57
  • @KevinReid Wonderful edits and clarifications. All crashes get deposited in /Library/Logs/DiagnosticReports and the. purged roughly after a month.
    – bmike ♦
    Commented Nov 18, 2020 at 2:03
  • Ah, that's perfect! If you could edit your answer to focus on that, I'd appreciate it.
    – Kevin Reid
    Commented Nov 18, 2020 at 2:05
  • @bmike to clarify, /Library/Logs/DiagnosticReports only seems to have crash reports for OS-level components. For user applications, the actual directory is $HOME/Library/Logs/DiagnosticReports instead.
    – Simon Kissane
    Commented Nov 9, 2022 at 22:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .