I'll simply copy this from LQ. Already have written to a couple of lists (including netbsd-users) but without results.

Running 7.0.2 with out of the box kernel. All my GTK+2 apps segfault on keyboard input. lxappearance for example, when looking for a theme you can start pressing keys and it will search. But in my case it dumps core with /usr/lib/libpthread.so.1, /usr/lib/libc.so.12 and /usr/pkg/lib/libXcursor.so.1. The same thing happens when typing something into a GTK+2 text editor, leafpad, or looking for something in Ctrl+O window in firefox or gimp or any other programme. gimp can't even run inside gdb because of:

I did memtests, once for four hours (two passes) and once for eight hours (eight passes). I did Dell's ePSA tests (diagnostic utility accessed from BIOS), it has own memtest, apart from monitoring the hard drive, the power supply, the keyboard, the fans, the CPU; all of them returned no errors. I rebuilt gtk2 with debug symbols but it changed nothing. On LQ it was suggested that I have hardware problems, but I am not convinced. Every programme described above worked inside Ubuntu LiveUSB
and Void Linux LiveUSB on the same machine (picked because they have different libc's). Before I had NetBSD with X11 a couple of months ago (and earlier) and I didn't have these errors. In the Interwebs
I found similar messages on Arch forum and Launchpad. Is there a need for a 24 hour memtest? Should I just remove each of the two memory modules and try? Is it hardware related after all?

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. 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.

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.

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.