Core-Dump auswerten

Computer: Software & Programmierung UNIX & Linux
#1

Hallo Leute

Wir haben hier ein SLES 9 SP3 64Bit im Einsatz.
cat /proc/version
Linux version 2.6.5-7.312-smp (geeko@buildhost) (gcc version 3.3.3 (SUSE Linux)) -1 SMP Fri Jun 6 12:44:33 UTC 2008

(jaja - ist schon etwas älter)

Darauf läuft eine relativ komplexe Java-Anwendung. Verwendet wird eine relativ aktuelle Java-VM
java -version
java version „1.6.0_27“
Java™ SE Runtime Environment (build 1.6.0_27-b07)
Java HotSpot™ 64-Bit Sever VM (build 20.2-b06, mixed mode)

Hin und wieder wird der Prozess offenbar vom Kernel zwangsbeendet.
dmesg
java[20264] bad frame in signal deliver frame:
java[20264]: segfault at error 6

Laut Suche im INet dürfte das Problem mit fehlerhaften Daten am Stack des Programms zusammenhängen. Vermutlich also eine Fehler der VM selbst.

Der Kernel hat auch einen core-dump geschrieben. Liegt im aktuellen Arbeitsverzeichnis des Prozesses und hat den Namen „core.11448“. Mich wundert, dass die Nummer eine andere ist als in der Kernel-Fehlermeldung, aber Meldung und Datei passen vom Datum/Uhrzeit her genau zusammen. Die Datei selbst ist ca. 4 GB gross.

Frage: kann ich mit diesem core-dump irgendwas sinnvolles anstellen? Soweit ich mich auskenne, ist die Datei ein Speicherabbild des Prozesses zum Zeitpunkt des Fehlers. Hilft mir aber nicht wirklich was weiter. Gibt es irgendeine Chance, das Problem wenigstens annähern einzugrenzen?

Die Java-Anwendung selbst ist eine reichlich komplexe Serveranwendung, mit der ein paar hundert Benutzer gleichzeitig arbeiten. Es ist eine proprietäre RMI-Anwendung und kein klassischer Applicationserver (also kein tomcat, jboss oder ähnliches). Die Logfiles der Java-Anwendung geben nichts her - es kam keine Java-Fehlermeldung, keine Stacktraces oder ähnliches. Es gibt auch keine Auffälligkeiten im Logfile des Garbage Collectors.

Danke schon mal für Hinweise

lg
Erwin

#2

Hallo Erwin,

Der Kernel hat auch einen core-dump geschrieben.

kann ich mit diesem core-dump irgendwas sinnvolles
anstellen?

Kommt drauf an. Für solche Fälle ist gdb dein Freund:

gdb program core-dump

program und core-dump natürlich entsprechend anpassen (s.a. man gdb)
Wenn Du nach

debuggen gdb tutorial

googelst. finden sich auch etliche Anleitungen dazu. Aber ob es nun tatsächlich weiterbringt, hängt mindestens stark von den Kenntnissen des Untersuchers ab…

Viele Grüße
Marvin

#3

hat sich zum glück erledigt
hallo

habe das problem anderweitig lösen können. der vollständigkeit halber:

das programm ist bei einer speziellen konstellation der daten in eine endlos-rekursion gekommen. eigentlich hätte ich da mit einem stackoverflow oder mit outofmemory gerechnet. dann wäre der böse thread beendet worden und die guten wären weitergelaufen. warum da aber die vm sich beendet, muss ich noch untersuchen. auf jeden fall scheint die vm noch mit linux-mitteln ein speicherabbild gezogen zu haben. da das aber im wesentlichen den heap darstellt, hätte ich damit vermutlich nichts anfangen können - ausser, ich hätte genau gewusst, wonach ich suchen müsste.

naja - inzwischen ist der datenfehler korrigiert und die anwendung läuft wieder so stabil wie vorher. zum glück also kein abtauchen in die untiefen von gdb.

lg
erwin