[erledigt] Hardware Problem? - segfault - Firefox, gnome-session-b

[OrangeJuice]

Ich habe hier auf meinem System(i5-10400,Mainboard H470) seit längerem einige Probleme gehabt. Nun stelle ich immer wieder fest, dass vor allem im Firefox(egal welcher Flatpakt, Debian ESR, mit Apparmor Profil unter Ubuntu...), segfaults entstehen.

Das ganze Jahr über stürzen mir entweder Tabs oder der ganze Browser ab. Eine Zeitlang, sogar mal ohne offene Webseite, manchmal, wenn Javascript in uBlock und Noscript für eine Webseite freigegeben wurde. Im Firefox unter about:crashes sind 20 Meldungen gelistet. Ein neues Profil hat nicht geholfen. Selten kommt es auch vor, dass andere Programme betroffen sein sollen.
Zur Zeit verwende ich ein Debian Bullseye mit Gnome Wayland, ein Ubuntu 21.10 ist ebenfalls auf einer Partition installiert. Dort passieren ebenfalls die segfaults.
Den Arbeitsspeicher habe ich in gewissen Abständen mit Memtest86 und memtester überprüft, es traten kein Fehler auf. Ein weiter Intel PC hat auch diese Art von segfaults, aber es stürzt kein Browser oder keine Tabs ab und unter about:crashes ist nichts aufgelistet.

Code: Alles auswählen

journalctl | grep -i segfault
Okt 02 12:35:00 user kernel: gnome-session-b[855]: segfault at 0 ip 00007fd088abcbe0 sp 00007ffde19d2e30 error 4 in libgobject-2.0.so.0.6600.8[7fd088a9f000+2f000]
Okt 25 16:48:14 user kernel: Isolated Web Co[7527]: segfault at 0 ip 00007fdd9a1505be sp 00007ffc44aac3f0 error 6 in libxul.so[7fdd94d19000+5449000]
Okt 28 09:23:08 user kernel: Isolated Web Co[2948]: segfault at 0 ip 00007f853e9f75be sp 00007fff07937390 error 6 in libxul.so[7f85395c0000+5449000]

ältere Fehler:

Code: Alles auswählen

flatpak run --socket=wayland --env=MOZ_ENABLE_WAYLAND=1 org.mozilla.firefox -P
Sandbox: seccomp sandbox violation: pid 224, tid 231, syscall 203, args 231 128 139624551529920 139624551533008 139624551532288

Code: Alles auswählen

MOZ_ENABLE_WAYLAND=1 firefox -P
###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

Corrupt JPEG data: 7 extraneous bytes before marker 0xe2
Corrupt JPEG data: 7 extraneous bytes before marker 0xe2
Corrupt JPEG data: 8 extraneous bytes before marker 0xee
Corrupt JPEG data: 7 extraneous bytes before marker 0xe2
Corrupt JPEG data: 7 extraneous bytes before marker 0xe2
Corrupt JPEG data: 8 extraneous bytes before marker 0xee

Die Ausgabe ist etwas kürzer, weil ich zwischendurch das System komplett neu auf einer NVME installiert habe, die vorherige SSD hat die segfaults dann wohl nicht verursacht.

Kann der Speicher so einen defekt habe, dass er immer mal wieder segfaults produziert, obwohl er laut Memtest fehlerfrei laufen soll?

[MSfree]

Kann der Speicher so einen defekt habe, dass er immer mal wieder segfaults produziert, obwohl er laut Memtest fehlerfrei laufen soll?

Ja, das ist durchaus möglich. Speichertests prüfen ja nur das Setzen bestimmter Bitmuster mit anschließendem Auslesen und Vergleich mit dem Sollmuster. Wenn die Speicherfehler aber nur sporadisch auftreten, z.B. weil ein paar Speicherzellen nicht ganz in Ordnung sind, dieses Fehlverhalten aber nur unter Bedingungen zeigen, die vom Speichertest nicht provoziert werden, kann so ein Fehler natürlich nicht nachgewiesen werden.

Man kann zwar die Anwesenheit von Fehlern zeigen, aber nie deren vollständige Abwesenheit.

Irgendwie hängt dein Problem natürlich mit falschen Speicherinhalten zusammen. Wie das aber zustande kommt, ist halt völlig unklar. Denkbar wäre auch kaputter Cache in der CPU oder ein defekter Speichecontroller (ebenfalls in der CPU). Natürlich kann auch jede Art von Kontaktproblemen im CPU-Sockel und/oder Speichersockeln solche Probleme verursachen oder auch jede Art des Betriebs ausserhalb der Spezifikationen, z.B. Übertaktung von RAM und/oder CPU.

Der i5-10400 ansich ist jedenfalls nicht dein Problem, diese CPU sitzt nämlich in dem Rechner, von dem ich das hier gerade schreibe, und meine Kiste läuft stabil.

Ich glaube zwar nicht so recht daran, daß es dein Problem lösen wird, aber installier sicherheitshalber mal das intel-microcode Paket aus non-free. Damit werden ein paar Errata in Intel-CPUs behoben, was aber nicht dafür garantiert, das ausgerechnet dein Problem dabei ist.

[OrangeJuice]

Danke für die Rückmeldung. Der Intel Microcode ist auf dem System schon installiert. Die CPU an sich macht eigentlich keine Probleme. In Benchmarks unter Windows, mit Prime95 und anderen Testprogrammen, lief sie problemlos. Es tauchten keine Hardwarefehler auf, sowie bei den Ryzen die ich früher mal hatte. Da schließt einen der defekt Intel CPU defekt oder Cache usw. nicht aus.

Als nächstes werde ich mir demnächst ein anderes Arbeitsspeicher-Kit kaufen und ausprobieren, wie es damit läuft.

Ich weiß nicht, wie es bei DDR4 aussieht, aber zu den älteren DDR-Arbeitsspeicher gab es mal eine Nachricht zu einer Studie.
Studie: DRAM-Speicherfehler viel häufiger als angenommen

[MSfree]

Ich weiß nicht, wie es bei DDR4 aussieht, aber zu den älteren DDR-Arbeitsspeicher gab es mal eine Nachricht zu einer Studie.
Studie: DRAM-Speicherfehler viel häufiger als angenommen

Ganz taufrisch ist die Studie natürlich nicht. Die fortschreitende Miniaturisierung in den einstelligen Nanometerbereich dürfte die Zuverlässigkeit jedenfalls nicht unbedingt positiv beeinflussen. Man kann nur hoffen, daß die Hersteller ihre Testverfahren auf Grund solcher Studien in den letzten 12 Jahren verbessert haben.

Hast du zwei Speicherriegel im Rechner? Dann könntest du einfach mal einen rausnehmen und schauen, ob das System dann stabiler wird.

[OrangeJuice]

Das ist ein guter Vorschlag. Es sind 2x8GB SO-DIMM verbaut(ist ein Deskmini PC). Ich habe nun ein Modul entfernt und werde beobachten wie es sich mit den segfaults verhält und dann nach einer gewissen Zeit das andere Modul, sowie die unterschiedlichen Slots testen.

Bei der Studie hatte ich noch einen Artikel zu den neuen DDR5 on-die ECC im Kopf(Abschnitt: "Do all DDR5 modules have ECC?"). Es könnte ja sein, dass die Fehlerrate teilweise schon sehr hoch ist bei DDR4.