Discussion:
Segfaults
Christian Knoke
2018-10-01 10:10:03 UTC
Permalink
Hallo,

ich nutze IPSEC um mich zum VPN-Anbieter zu verbinden. Das System ist Devuan Ascii, also weitgehend identisch mit Debian Stretch.

Seit ein paar Tagen bekomme ich segfaults, laut kern.log heute folgende:

Oct 1 11:42:57 leo kernel: [ 2760.312300] egrep[6489]: segfault at 426e54 ip 00419246 sp bfef4088 error 7 in dash[408000+1d000]
Oct 1 11:42:57 leo kernel: [ 2760.326221] ipsec[6492]: segfault at 4d8e54 ip 004cb246 sp bf8a3628 error 7 in dash[4ba000+1d000]
Oct 1 11:43:09 leo kernel: [ 2771.641090] egrep[6502]: segfault at 4b0e54 ip 004a3246 sp bf916e98 error 7 in dash[492000+1d000]
Oct 1 11:43:09 leo kernel: [ 2771.654892] ipsec[6505]: segfault at 50ae54 ip 004fd246 sp bff812a8 error 7 in dash[4ec000+1d000]
Oct 1 11:43:16 leo kernel: [ 2778.733969] ipsec[6513]: segfault at 4f8e54 ip 004eb246 sp bff6be18 error 7 in dash[4da000+1d000]
Oct 1 11:45:01 leo kernel: [ 2884.261407] sh[6570]: segfault at 44ee54 ip 00441246 sp bf803b08 error 7 in dash[430000+1d000]
Oct 1 11:49:01 leo kernel: [ 3123.760096] sh[6731]: segfault at 4dfe54 ip 004d2246 sp bffcc478 error 7 in dash[4c1000+1d000]
Oct 1 11:49:01 leo kernel: [ 3123.834954] sh[6732]: segfault at 47fe54 ip 00472246 sp bfb6f978 error 7 in dash[461000+1d000]
Oct 1 11:49:07 leo kernel: [ 3129.579042] sh[6740]: segfault at 464e54 ip 00457246 sp bfd0f578 error 7 in dash[446000+1d000]
Oct 1 11:49:17 leo kernel: [ 3139.961932] sh[6746]: segfault at 4e0e54 ip 004d3246 sp bff6bcc8 error 7 in dash[4c2000+1d000]
Oct 1 11:49:18 leo kernel: [ 3140.674438] sh[6747]: segfault at 41ee54 ip 00411246 sp bf9d4e08 error 7 in dash[400000+1d000]
Oct 1 11:49:53 leo kernel: [ 3175.570971] sh[6766]: segfault at 467e54 ip 0045a246 sp bfcbe818 error 7 in dash[449000+1d000]
Oct 1 11:50:33 leo kernel: [ 3216.067566] sh[6798]: segfault at 503e54 ip 004f6246 sp bfd70198 error 7 in dash[4e5000+1d000]
Oct 1 11:53:05 leo kernel: [ 3368.087741] sh[6895]: segfault at 425e54 ip 00418246 sp bf93c6e8 error 7 in dash[407000+1d000]
Oct 1 11:53:05 leo kernel: [ 3368.154854] sh[6896]: segfault at 485e54 ip 00478246 sp bfcb5da8 error 7 in dash[467000+1d000]
Oct 1 11:53:09 leo kernel: [ 3371.857798] sh[6904]: segfault at 4f7e54 ip 004ea246 sp bfc894b8 error 7 in dash[4d9000+1d000]
Oct 1 11:53:15 leo kernel: [ 3377.408246] sh[6905]: segfault at 48ce54 ip 0047f246 sp bf8951a8 error 7 in dash[46e000+1d000]
Oct 1 11:53:16 leo kernel: [ 3378.429724] sh[6906]: segfault at 431e54 ip 00424246 sp bfe1bc58 error 7 in dash[413000+1d000]
Oct 1 11:53:25 leo kernel: [ 3388.290962] sh[6912]: segfault at 47fe54 ip 00472246 sp bfe3cc68 error 7 in dash[461000+1d000]
Oct 1 11:55:01 leo kernel: [ 3484.267818] sh[6979]: segfault at 50de54 ip 00500246 sp bfaf0338 error 7 in dash[4ef000+1d000]
Oct 1 11:55:45 leo kernel: [ 3528.105365] sh[7009]: segfault at 473e54 ip 00466246 sp bf957248 error 7 in dash[455000+1d000]
Oct 1 11:55:50 leo kernel: [ 3533.220037] sh[7017]: segfault at 4f4e54 ip 004e7246 sp bfec7a98 error 7 in dash[4d6000+1d000]
Oct 1 11:55:59 leo kernel: [ 3541.616130] sh[7023]: segfault at 4e8e54 ip 004db246 sp bfca6e28 error 7 in dash[4ca000+1d000]
Oct 1 11:56:00 leo kernel: [ 3542.633052] sh[7024]: segfault at 456e54 ip 00449246 sp bfd4c0b8 error 7 in dash[438000+1d000]
Oct 1 12:00:01 leo kernel: [ 3784.273639] sh[7148]: segfault at 466e54 ip 00459246 sp bfe6bf58 error 7 in dash[448000+1d000]

Heute gibt es folgenden (reproduzierbaren) Fehler:
***@......:~# ipsec status
Speicherzugriffsfehler

~# strace -f -o ipsec3 ipsec status

Den Output kann ich zwar lesen, aber nur schwer verstehen. Kann mir dazu jemand sicherheitstechnisch etwas sagen? Die Ausgabe ist nicht sehr lang, daher hier komplett. Mutt ist wohl auch betroffen, wollte keine Mail verfassen.

6661 execve("/usr/sbin/ipsec", ["ipsec", "status"], [/* 14 vars */]) = 0
6661 brk(NULL) = 0x1b7e000
6661 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
6661 mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7765000
6661 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
6661 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
6661 fstat64(3, {st_mode=S_IFREG|0644, st_size=178410, ...}) = 0
6661 mmap2(NULL, 178410, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7739000
6661 close(3) = 0
6661 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
6661 open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
6661 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\204\1\0004\0\0\0"..., 512) = 512
6661 fstat64(3, {st_mode=S_IFREG|0755, st_size=1787812, ...}) = 0
6661 mmap2(NULL, 1796604, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7582000
6661 mmap2(0xb7733000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b0000) = 0xb7733000
6661 mmap2(0xb7736000, 10748, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7736000
6661 close(3) = 0
6661 set_thread_area({entry_number:-1, base_addr:0xb7767840, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:6)
6661 mprotect(0xb7733000, 8192, PROT_READ) = 0
6661 mprotect(0x462000, 4096, PROT_READ) = 0
6661 mprotect(0xb778f000, 4096, PROT_READ) = 0
6661 munmap(0xb7739000, 178410) = 0
6661 getpid() = 6661
6661 rt_sigaction(SIGCHLD, {sa_handler=0x454a30, sa_mask=~[RTMIN RT_1], sa_flags=0}, NULL, 8) = 0
6661 geteuid32() = 0
6661 brk(NULL) = 0x1b7e000
6661 brk(0x1b9f000) = 0x1b9f000
6661 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x462e54} ---
6661 +++ killed by SIGSEGV +++

Gruß
Christian
--
*** Christian Knoke * 25541 Brunsbüttel * http://cknoke.de ***
... ...
The prejudices people feel about each other disappear when they
get to know each other. -- Kirk, "Elaan of Troyius", stardate 4372.5
Martin Reising
2018-10-01 16:29:44 UTC
Permalink
Post by Christian Knoke
Hallo,
ich nutze IPSEC um mich zum VPN-Anbieter zu verbinden. Das System ist Devuan Ascii, also weitgehend identisch mit Debian Stretch.
Oct 1 11:42:57 leo kernel: [ 2760.312300] egrep[6489]: segfault at 426e54 ip 00419246 sp bfef4088 error 7 in dash[408000+1d000]
Oct 1 11:42:57 leo kernel: [ 2760.326221] ipsec[6492]: segfault at 4d8e54 ip 004cb246 sp bf8a3628 error 7 in dash[4ba000+1d000]
Oct 1 11:43:09 leo kernel: [ 2771.641090] egrep[6502]: segfault at 4b0e54 ip 004a3246 sp bf916e98 error 7 in dash[492000+1d000]
Oct 1 11:43:09 leo kernel: [ 2771.654892] ipsec[6505]: segfault at 50ae54 ip 004fd246 sp bff812a8 error 7 in dash[4ec000+1d000]
Oct 1 11:43:16 leo kernel: [ 2778.733969] ipsec[6513]: segfault at 4f8e54 ip 004eb246 sp bff6be18 error 7 in dash[4da000+1d000]
Oct 1 11:45:01 leo kernel: [ 2884.261407] sh[6570]: segfault at 44ee54 ip 00441246 sp bf803b08 error 7 in dash[430000+1d000]
Oct 1 11:49:01 leo kernel: [ 3123.760096] sh[6731]: segfault at 4dfe54 ip 004d2246 sp bffcc478 error 7 in dash[4c1000+1d000]
Oct 1 11:49:01 leo kernel: [ 3123.834954] sh[6732]: segfault at 47fe54 ip 00472246 sp bfb6f978 error 7 in dash[461000+1d000]
Oct 1 11:49:07 leo kernel: [ 3129.579042] sh[6740]: segfault at 464e54 ip 00457246 sp bfd0f578 error 7 in dash[446000+1d000]
Oct 1 11:49:17 leo kernel: [ 3139.961932] sh[6746]: segfault at 4e0e54 ip 004d3246 sp bff6bcc8 error 7 in dash[4c2000+1d000]
Oct 1 11:49:18 leo kernel: [ 3140.674438] sh[6747]: segfault at 41ee54 ip 00411246 sp bf9d4e08 error 7 in dash[400000+1d000]
Oct 1 11:49:53 leo kernel: [ 3175.570971] sh[6766]: segfault at 467e54 ip 0045a246 sp bfcbe818 error 7 in dash[449000+1d000]
Oct 1 11:50:33 leo kernel: [ 3216.067566] sh[6798]: segfault at 503e54 ip 004f6246 sp bfd70198 error 7 in dash[4e5000+1d000]
Oct 1 11:53:05 leo kernel: [ 3368.087741] sh[6895]: segfault at 425e54 ip 00418246 sp bf93c6e8 error 7 in dash[407000+1d000]
Oct 1 11:53:05 leo kernel: [ 3368.154854] sh[6896]: segfault at 485e54 ip 00478246 sp bfcb5da8 error 7 in dash[467000+1d000]
Oct 1 11:53:09 leo kernel: [ 3371.857798] sh[6904]: segfault at 4f7e54 ip 004ea246 sp bfc894b8 error 7 in dash[4d9000+1d000]
Oct 1 11:53:15 leo kernel: [ 3377.408246] sh[6905]: segfault at 48ce54 ip 0047f246 sp bf8951a8 error 7 in dash[46e000+1d000]
Oct 1 11:53:16 leo kernel: [ 3378.429724] sh[6906]: segfault at 431e54 ip 00424246 sp bfe1bc58 error 7 in dash[413000+1d000]
Oct 1 11:53:25 leo kernel: [ 3388.290962] sh[6912]: segfault at 47fe54 ip 00472246 sp bfe3cc68 error 7 in dash[461000+1d000]
Oct 1 11:55:01 leo kernel: [ 3484.267818] sh[6979]: segfault at 50de54 ip 00500246 sp bfaf0338 error 7 in dash[4ef000+1d000]
Oct 1 11:55:45 leo kernel: [ 3528.105365] sh[7009]: segfault at 473e54 ip 00466246 sp bf957248 error 7 in dash[455000+1d000]
Oct 1 11:55:50 leo kernel: [ 3533.220037] sh[7017]: segfault at 4f4e54 ip 004e7246 sp bfec7a98 error 7 in dash[4d6000+1d000]
Oct 1 11:55:59 leo kernel: [ 3541.616130] sh[7023]: segfault at 4e8e54 ip 004db246 sp bfca6e28 error 7 in dash[4ca000+1d000]
Oct 1 11:56:00 leo kernel: [ 3542.633052] sh[7024]: segfault at 456e54 ip 00449246 sp bfd4c0b8 error 7 in dash[438000+1d000]
Oct 1 12:00:01 leo kernel: [ 3784.273639] sh[7148]: segfault at 466e54 ip 00459246 sp bfe6bf58 error 7 in dash[448000+1d000]
Bei so einem Fehlerbild gehe ich von defektem RAM aus.
Also mal über Nacht memtest laufen lassen.
Christian Knoke
2018-10-01 18:52:24 UTC
Permalink
Post by Martin Reising
Post by Christian Knoke
Hallo,
ich nutze IPSEC um mich zum VPN-Anbieter zu verbinden. Das System ist
Devuan Ascii, also weitgehend identisch mit Debian Stretch.
Oct 1 11:42:57 leo kernel: [ 2760.312300] egrep[6489]: segfault at 426e54 ip 00419246 sp bfef4088 error 7 in dash[408000+1d000]
Oct 1 11:42:57 leo kernel: [ 2760.326221] ipsec[6492]: segfault at 4d8e54 ip 004cb246 sp bf8a3628 error 7 in dash[4ba000+1d000]
Oct 1 11:43:09 leo kernel: [ 2771.641090] egrep[6502]: segfault at 4b0e54 ip 004a3246 sp bf916e98 error 7 in dash[492000+1d000]
Oct 1 11:43:09 leo kernel: [ 2771.654892] ipsec[6505]: segfault at 50ae54 ip 004fd246 sp bff812a8 error 7 in dash[4ec000+1d000]
Oct 1 11:43:16 leo kernel: [ 2778.733969] ipsec[6513]: segfault at 4f8e54 ip 004eb246 sp bff6be18 error 7 in dash[4da000+1d000]
Oct 1 11:45:01 leo kernel: [ 2884.261407] sh[6570]: segfault at 44ee54 ip 00441246 sp bf803b08 error 7 in dash[430000+1d000]
Oct 1 11:49:01 leo kernel: [ 3123.760096] sh[6731]: segfault at 4dfe54 ip 004d2246 sp bffcc478 error 7 in dash[4c1000+1d000]
Oct 1 11:49:01 leo kernel: [ 3123.834954] sh[6732]: segfault at 47fe54 ip 00472246 sp bfb6f978 error 7 in dash[461000+1d000]
Oct 1 11:49:07 leo kernel: [ 3129.579042] sh[6740]: segfault at 464e54 ip 00457246 sp bfd0f578 error 7 in dash[446000+1d000]
Oct 1 11:49:17 leo kernel: [ 3139.961932] sh[6746]: segfault at 4e0e54 ip 004d3246 sp bff6bcc8 error 7 in dash[4c2000+1d000]
*snip*
Post by Martin Reising
Bei so einem Fehlerbild gehe ich von defektem RAM aus.
Also mal über Nacht memtest laufen lassen.
Ah danke, dass ist natürlich ein Hinweis. Die einfachste Erklärung
jedenfalls.

Könnte auch die Fehler in der shared memory Graphik erklären, die manchmal
auftreten.

Gruß
Christian
--
*** Christian Knoke * 25541 Brunsbüttel * http://cknoke.de ***
Christian Knoke
2018-10-02 11:12:17 UTC
Permalink
Post by Martin Reising
Post by Christian Knoke
Oct 1 11:42:57 leo kernel: [ 2760.312300] egrep[6489]: segfault at 426e54 ip 00419246 sp bfef4088 error 7 in dash[408000+1d000]
Oct 1 11:42:57 leo kernel: [ 2760.326221] ipsec[6492]: segfault at 4d8e54 ip 004cb246 sp bf8a3628 error 7 in dash[4ba000+1d000]
Bei so einem Fehlerbild gehe ich von defektem RAM aus.
Also mal über Nacht memtest laufen lassen.
memtest86+ meldet nach 3,5 Minuten folgenden Fehlereintrag:

TST PASS Failing Adress Good Bad Bits Counts CPU
1 0 0007f694240 - 2028,2 MB fffffbff ffff7bff 00008000 1 0

Weitere Läufe, auch von memtest86, bestätigen die Adresse. Nach 2 Stunden
und 2 vollständigen Passes habe ich aus thermischen Gründen abgebrochen.

Weitere Einträge gab es nicht, wohl aber rechts oben in der Anzeige:
Errors: 126

Worauf bezieht sich die Zahl? Sind das weitere Auftreten desselben Fehlers?
Beim Adresseintrag bleibt der "Count" auf 1 stehen.

Jetzt suche ich nach dem richtigen Kernelparameter für den Bad RAM Patch
im Google-Meer.

memtester gibt einen Fehler:

***@...:~# memtester -p 0007f694000 1
memtester version 4.3.0 (32-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffff000
want 1MB (1048576 bytes)
failed to mmap /dev/mem for physical memory: Operation not permitted

Gruß
Christian
--
*** Christian Knoke * 25541 Brunsbüttel * http://cknoke.de ***
... ...
The prejudices people feel about each other disappear when they
get to know each other. -- Kirk, "Elaan of Troyius", stardate 4372.5
Jonny
2018-10-03 12:00:09 UTC
Permalink
Post by Christian Knoke
Errors: 126
Worauf bezieht sich die Zahl? Sind das weitere Auftreten desselben Fehlers?
Beim Adresseintrag bleibt der "Count" auf 1 stehen.
Genau, ein Fehler trat mehrfach an der selben Stelle auf.
Post by Christian Knoke
Jetzt suche ich nach dem richtigen Kernelparameter für den Bad RAM Patch
im Google-Meer.
Du könntest dem Kernel sagen, dass er nur 2024 MB nutzen soll:
mem=2024M

In deinem Fall geht das sogar weitgehend schmerzlos, weil der Fehler
am oberen Ende des Adressraums liegt. Du verschenkst somit 24 MB.

Alternativ kannst du den defekten RAM ausklammern. Das kann GRUB2 für
dich übernehmen. Dazu musst du den defekten Bereich in
/etc/default/grub definieren:
GRUB_BADRAM=0x7f690000,0xffff0000

Damit veranlasst GRUB, dass der Kernel einen 64 kB großen Block (Maske
0xffff0000) oberhalb von 0x7f690000 auslässt. Da dein Fehler an
0x7f694240 liegt, sollte das passen.
--
Gruß
Jonny
Frank Lanitz
2018-10-03 13:24:13 UTC
Permalink
Post by Jonny
Post by Christian Knoke
Errors: 126
Worauf bezieht sich die Zahl? Sind das weitere Auftreten desselben Fehlers?
Beim Adresseintrag bleibt der "Count" auf 1 stehen.
Genau, ein Fehler trat mehrfach an der selben Stelle auf.
Post by Christian Knoke
Jetzt suche ich nach dem richtigen Kernelparameter für den Bad RAM Patch
im Google-Meer.
mem=2024M
In deinem Fall geht das sogar weitgehend schmerzlos, weil der Fehler
am oberen Ende des Adressraums liegt. Du verschenkst somit 24 MB.
Alternativ kannst du den defekten RAM ausklammern. Das kann GRUB2 für
dich übernehmen. Dazu musst du den defekten Bereich in
GRUB_BADRAM=0x7f690000,0xffff0000
Damit veranlasst GRUB, dass der Kernel einen 64 kB großen Block (Maske
0xffff0000) oberhalb von 0x7f690000 auslässt. Da dein Fehler an
0x7f694240 liegt, sollte das passen.
Kann man tun -- Tauschen wäre die bessere Idee. Nur weil memtest an
anderer Stelle nichts findet, kann es dort trotzdem ein Problem geben.
Das verursacht potentiell Flugrost über das das ganze System inkl.
heimlich gekippte Bits (bei falschen Dateisystemen) in Dateien.

Gruß Frank
Christoph Schmees
2018-10-03 13:49:03 UTC
Permalink
Post by Jonny
Post by Christian Knoke
Errors: 126
Worauf bezieht sich die Zahl? Sind das weitere Auftreten desselben Fehlers?
Beim Adresseintrag bleibt der "Count" auf 1 stehen.
Genau, ein Fehler trat mehrfach an der selben Stelle auf.
Post by Christian Knoke
Jetzt suche ich nach dem richtigen Kernelparameter für den Bad RAM Patch
im Google-Meer.
mem=2024M
In deinem Fall geht das sogar weitgehend schmerzlos, weil der Fehler
am oberen Ende des Adressraums liegt. Du verschenkst somit 24 MB.
Alternativ kannst du den defekten RAM ausklammern. Das kann GRUB2 für
dich übernehmen. Dazu musst du den defekten Bereich in
GRUB_BADRAM=0x7f690000,0xffff0000
Damit veranlasst GRUB, dass der Kernel einen 64 kB großen Block (Maske
0xffff0000) oberhalb von 0x7f690000 auslässt. Da dein Fehler an
0x7f694240 liegt, sollte das passen.
ähm - das halte ich für eine schlechte Idee.

Wenn RAM kaputt, RAM austauschen!

Das kostet ein paar nEuronen, aber erspart möglicherweise viel Ärger
mit "unerklärlichem" Systemverhalten.

Vielleicht ist aber gar nicht RAM kaputt, sondern das Mainboard.
Solche Fehler können auch durch das berüchtigte Elko-Sterben
verursacht werden. Bei zwei Riegeln: testweise vertauschen. Wandert
der Fehler mit? Oder leihweise anderes RAM reinstecken.

Mit einem RAM, das an *irgendeiner* Stelle einen Fehler hat, würde
ich keinesfalls arbeiten. Außer es ist egal, weil die Büchse nur zum
Zocken gebraucht wird.

meine 2¢
Christoph
--
Bitte keine Mails von USA-Providern wie AOL, me.com (Apple),
gmail (Google), hotmail/outlook.com (Microsoft) oder yahoo.
Solche Mails werden ohne Rückmeldung gelöscht.
Siehe <http://www.pc-fluesterer.info/wordpress/downloads>
Jonny
2018-10-03 22:26:05 UTC
Permalink
Post by Christoph Schmees
Wenn RAM kaputt, RAM austauschen!
Das sehe ich genauso, aber er hatte ja explizit danach gefragt.
--
Gruß
Jonny
Christian Knoke
2018-10-04 09:37:35 UTC
Permalink
Post by Jonny
Post by Christian Knoke
Errors: 126
Worauf bezieht sich die Zahl? Sind das weitere Auftreten desselben Fehlers?
Beim Adresseintrag bleibt der "Count" auf 1 stehen.
Genau, ein Fehler trat mehrfach an der selben Stelle auf.
Post by Christian Knoke
Jetzt suche ich nach dem richtigen Kernelparameter für den Bad RAM Patch
im Google-Meer.
mem=2024M
In deinem Fall geht das sogar weitgehend schmerzlos, weil der Fehler
am oberen Ende des Adressraums liegt. Du verschenkst somit 24 MB.
Alternativ kannst du den defekten RAM ausklammern. Das kann GRUB2 für
dich übernehmen. Dazu musst du den defekten Bereich in
GRUB_BADRAM=0x7f690000,0xffff0000
Damit veranlasst GRUB, dass der Kernel einen 64 kB großen Block (Maske
0xffff0000) oberhalb von 0x7f690000 auslässt. Da dein Fehler an
0x7f694240 liegt, sollte das passen.
Vielen Dank! Ich habe jetzt erstmal mem=2024m eingesetzt und werde
beobachten.

Bezüglich der Warnungen, den RAM auszutauschen, dass sehe ich eher relaxed.
Es laufen keine unternehmenskritische Anwendungen ;-) Auch war die Ausgabe
vom memtest ja recht klar. Vielen Dank für alle Hinweise!

Gruß
Christian
--
*** Christian Knoke * 25541 Brunsbüttel * http://cknoke.de ***
... ...
The prejudices people feel about each other disappear when they
get to know each other. -- Kirk, "Elaan of Troyius", stardate 4372.5
Christian Knoke
2018-10-02 11:47:51 UTC
Permalink
Hallo Marc,
On Mon, 1 Oct 2018 18:29:44 +0200, Martin Reising
Post by Martin Reising
Bei so einem Fehlerbild gehe ich von defektem RAM aus.
Oder irgend ein anderes Hardwareproblem. Es ist unwahrscheinlich, dass
so viele Programme gleichzeitig fehlerhaft wurden.
Oder gab es ein Update einer zentralen Library? Treten die Segfaults
auch nach einem Reset noch auf?
Nach dem Reset gestern traten keine Segfaults mehr auf. Es war aber nicht
das erste Mal. Am 23. September zum Beispiel:
Sep 30 23:27:35 leo kernel: [25957.825593] xfce4-sensors-p[2570]: segfault at b8a3edcc ip b6c57260 sp bfe7f570 error 4 in libc-2.24.so[b6be9000+1b1000]
Sep 23 18:28:28 leo kernel: [ 4663.388942] zoom[8089]: segfault at 76 ip b7393240 sp bfee8dbc error 4 in libc-2.24.so[b729f000+1b1000]
Sep 23 18:28:54 leo kernel: [ 4690.055208] stroke[8368]: segfault at 76 ip b75e1240 sp bff5df9c error 4 in libc-2.24.so[b74ed000+1b1000]
Sep 23 18:28:56 leo kernel: [ 4692.035721] stroke[8403]: segfault at 76 ip b7601240 sp bfa95e9c error 4 in libc-2.24.so[b750d000+1b1000]
[...]

sowie am 11., 14., 21., und 22. An allen anderen Nutzungstagen nicht.

An eine Library hatte ich auch zuerst gedacht. Vielleicht eine Library die
an die BadRAM Stelle geladen wurde? memtest86+ gibt die Stelle mit 2038.2 MB
an. Der Speicher ist 2 GB groß. Wird der Kernel nicht ganz oben hin geladen?

Ein Upgrade einer zentralen Library sehe ich gerade nicht - das wären dann
die von Stretch.
Grüße
Marc
Gruß
Christian
--
*** Christian Knoke * 25541 Brunsbüttel * http://cknoke.de ***
... ...
The prejudices people feel about each other disappear when they
get to know each other. -- Kirk, "Elaan of Troyius", stardate 4372.5
Lesen Sie weiter auf narkive:
Loading...