Unless you can reproduce it, I don't think we can reject the "null hypothesis" that the crash was caused by something unrelated (e.g. hardware problem) that just coincidentally happened to occur during this particular task.
I fully agree. I haven't decided whether I'm hoping I can reproduce it, or whether I'm hoping I can't.
I would say that this is an almost fallacious way to look at things, honestly. urxvt is a userspace application, so it "can't" crash the system, no matter what I do with it... right? Even if I run `sudo /usr/sbin/crashsystem`, it's running in a userspace application, what can it do really?
I disagree. With neither a setuid binary nor my password, it would be a major problem if a userspace application is allowed to crash the system. If a buggy application can do so accidentally, then a malicious application can do so deliberately.
Userspace applications have to make use of kernel facilities for everything they do, such as displaying graphics on the screen. A not-entirely-uncommon cause of system crashes is bugs being triggered in a GPU driver.
Yes, I forgot to mention that. I specifically included the details about the GPU driver and kernel modules because I'm guessing that urxvt (or maybe Xorg) triggered a bug in the GPU driver. I suppose terminal beeps could trigger a bug in an audio driver, but audio drivers always seemed more stable to me.
-MD