Quote:
Originally Posted by jggimi
I don't know, I don't speak NetBSD. But "segfaults everywhere" always smell like hardware if they are not repeatable. Repeatable segfaults are more likely to be software. If these are repeatable, then yes, a broken, misconfigured system is possible.
|
The thing is, I had something similar on Alpine Linux previously, all these things started to segfault at one point for some reason. I didn't debug them back then (it was in December on the same machine), so I didn't know what was the reason.
Quote:
|
On my BSD variant, we talk a lot about "Frankensystems" where people mix bits and pieces of different releases, different flavors, which can lead either to problems or to unmaintainability, or both.
|
Here we can have something similar, I once used current pkgsrc tree on a stable release system and it wasn't good. I no longer do this.
Quote:
To the best of my recollection, I've only seen "real" SIGILL signals on i386 variants that have limited capabilities. It's primarily why I asked for a dmesg -- thought it may be helpful to NetBSD users who reply to this thread. You're running an amd64 system on an Ivy Bridge CPU, which may be helpful for them to know.
Any other SIGILLs I can remember seeing have been seen on a branch to a bad instruction address. Those go hand-in-hand with SIGSEGVs, as one is a branch, the other a reference.
|
If running inside gdb mplayer reports SIGSEGV, if alone then SIGILL.