On Thu, May 8, 2025, 22:23 Nate Eldredge <n...@thatsmathematics.com> wrote:
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. On Thu, May 8, 2025, 22:59 Eli Schwartz <eschwa...@gentoo.org> wrote: > 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 >
