Hallo David, hallo Thomas, hallo Leute, da bin ich wieder mit meinem Kernel ;-) Am Donnerstag, 06. November 2003 01:31 schrieb David Haller:
Am Thu, 06 Nov 2003, Christian Boltz schrieb:
Am Sonntag, 2. November 2003 23:42 schrieb Christian Boltz:
Am Sonntag, 2. November 2003 00:13 schrieb David Haller:
Am Sat, 01 Nov 2003, Christian Boltz schrieb:
ich habe hier seit kurzem SuSE 9.0 Pro installiert (als Update [1]) und das Problem, dass sich einige Programme mit segfault "verabschieden". Bisher habe ich das Problem bei den Programmen sleep, hwclock, ps, awk [...] festgestellt.
Der Fehler scheint irgendwie mit dem Kernel zusammenzuhängen, da mit meinem "alten" 2.4.16-vanilla [...] o. g. Programme laufen. Der SuSE-Kernel, der die Probleme macht, ist k_deflt-2.4.21-99.
Der Meinung bin ich übrigens immer noch ;-)
Scheint so. Dummerweise kenne ich die SuSE-Kernels nicht genau genug.
Aehm, sind dein *utils (bes. procps) usw. auf dem noetigen Stand
Das will ich bei SuSE 9.0 doch hoffen ;-) Ich hab grad mal ein for file in `rpm -qa` ; do rpm -qi $file | \ grep "Distribution: SuSE Linux 9.0" >/dev/null || echo $file ; done durchlaufen lassen - gibt eine Liste mit 27 Paketen. Wenn ich davon die uninteressanten Pakete (also Perl-Module, Doku usw.) rausstreiche, bleibt an möglicherweise interessanten Paketen: cdfs-0.5c-1 (für den "alten" vanilla kompiliert + checkinstall *duck*) idesmart-1.4-41 (von SuSE 8.2) nssv1-2.1.3-141 (stammt noch von SuSE 7.0 und enthält: (rpm -ql) /lib/libnss_compat.so.1 /lib/libnss_db.so.1 /lib/libnss_dns.so.1 /lib/libnss_files.so.1 /lib/libnss_nis.so.1 Alle anderen Pakete gehören zu SuSE 9.0
Und koenntest du evtl. einen Vanilla 2.4.21 mal testen?
Hatte ich vor und hab mir dann bei einem Bekannten mit DSL die Vanilla-Sourcen runtergeladen. Ich hab nur scheinbar schlecht gezielt, es ist ein 2.4.22 ;-) Jedenfalls: Auch mit dem neuen Vanilla-Kernel tauchen keine SegFaults auf - irgendwie hab ich das Gefühl, dass die Schuld wirklich beim SuSE-Kernel liegt... BTW, um auch das auszuschließen: rpm -V k_deflt findet keine Veränderungen am SuSE-Kernel. [...]
Und dann verwende 'ltrace -f -s 64 -S -o <logdatei>' zum tracen. [...] [Anscheinend normaler Programmablauf, also kein Fehlerhandling etc.]
1764 getopt_long(2, 0xbffff4c4, "+", 0x0804a680, NULL) = -1 1764 getopt_long(2, 0xbffff4c4, "", 0x0804a3a8, NULL) = -1 1764 __errno_location() = 0x4019a360 1764 __strtod_internal(0xbffff65f, 0xbffff404, 0, 0x401311f1, 2
1764 --- SIGSEGV (Segmentation fault) --- 1764 +++ killed by SIGSEGV +++ Wenn ich mit meinem 2.4.16-vanilla boote, läuft alles problemlos
Das spricht dann fuer nen Kernel-Bug (und eben einem in einem der zwischen 2.4.16-vanilla und 2.4.21-SuSE)... Waere also gut, wenn du das eingrenzen koenntest.
Wie gesagt, mit einem neuen Vanilla 2.4.22 läuft es. Die Kernelconfig habe ich weitgehend vom SuSE-Kernel übernommen, neue Optionen auf den Defaultwert. Einzige Änderung: ext3 und jfs sind fest einkompiliert.
An der glibc hast du nicht geschraubt, oder?
Nö, da lass ich die Finger davon ;-)
Denn sscanf bzw. __strod_internal sind glibc-Funktionen (bei syscalls wuerde die Praefix SYS_ verwendet werden, wie oben beim SYS_exit)... Und wie man weiter oben sieht werden syscalls aus der glibc beim 'ltrace -S' schoen aufgefuehrt (zu sehen z.B. am fprintf nach dem Segfault in ps). Der Segfault tritt also in der glibc auf...
Das macht die Sache wohl nicht einfacher ;-)
PS@Thomas: Dein Link zu sig11-Ursachen ist eine interessante Lektüre, allerdings hab ich auf Anhieb nix "passendes" gefunden ;-)
Hmjo, ich denke, hier sind die SuSEianer gefordert, speziell Thorsten und Philipp, die sich mit glibc und Kernel besser auskennen als ich.
Jepp - würde mich freuen, wenn jemand von SuSE mal drüberschaut ;-)
PS: Gibt's nen besonderen Grund fuer den neuen Kernel?
Naja, ich hab die SuSE 9.0 installiert und dann mal mehr spasseshalber den zugehörigen Kernel gebootet. Und die segfaults in so grundlegenden Programmen machen einen dann schon stutzig...
Und dann fuer nen SuSE-Kernel?
Gilt "Der bunte Rahmen gefällt mir"? ;-) Ansonsten s. o.
Und warum nicht gleich 2.6.*?
So experimentierfreudig bin ich beim Kernel nicht - wenn ich eine Beta [1] will, dann bei KDE ;-) Gruß Christian Boltz [1] Klar, Kernel 2.6.0 ist wohl offiziell nicht "Beta", aber eben auch noch verhältnismäßig wenig getestet. Und eine .0 beim Kernel versuche ich zu vermeiden ;-) --
Habe auch vor die Festplatte zu tauchen. Aber bevor ich diesen Tauch- prozess durchziehe, will ich auch eine andere Ursache nicht aus- schliessen, dass evtl. auch die Festplatte einen latenten Defekt hat. Hm, und in was taucht ihr die Festplatten? Heißwachs, Leinöl, ..? [> Pieter Wenk und Matthias Houdek in suse-linux]