Fatal error der JVM

[bygones]

Hi,

ich sitz gerade bei einem Kunde und deren Javabuild fliegt mittlerweilen regelmäßig raus mit einem Java Fatal error

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000000000000038, pid=7009, tid=139650159224592
#
# JRE version: 6.0_22-b04
# Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode linux-amd64 )
# Problematic frame:
# C 0x0000000000000038
#
# An error report file with more information is saved as:
# /home/foo/WORKDIR/jobs/test/workspace/testjob/bar/hs_err_pid7009.log
#
# If you would like to submit a bug report, please visit:
# HotSpot Virtual Machine Error Reporting Page
#

Auf dem Rechner ist ein Suse Linux Enterprise Server 11.1 x64. Es war ein JDK 6.0_20 64bit installiert, wir haben es dann auch mit einem 6.0_22 64bit probiert.

hat jemand Erfahrung mit der Problematik (habe mal das ganze log angehängt)

Für Hinweise dankend

Edit: Der Abbruch geschieht zu unterschiedlichen "Zeiten", also an untersch. Stellen. Somit ist nicht offensichtlich ob eine bestimmte Codestelle bzw eine da gerade verwendetet Library die Probleme auslöst,

 

[FArt]

Tritt der Fehler immer im Zusammenhang mit geforkten JUnit Tests aus dem ANT auf?

 

[fastjack]

SIGSEGV ist meiner Meinung nach ein Fehler beim Speicherzugriff.

* Falls mehrere Javas installiert sind, versuche mal alle bis auf das letzte installierte zu entfernen. Bei uns gab es ähnliche Probleme, weil mehrere JRE's (OpenJDK und Sun) manuell installiert waren (32bit und 64bit teilten sich dann dieselben .so-Dateien).

* Ansonsten gab es bei uns Probleme mit Java-Maschinen, die nicht von Sun waren und unregelmäßig SIGSEGV's schmissen (Diablo Java und OpenJDK machten da Probleme).

 

[fastjack]

Ansonsten fällt mir noch das tracen des Fehler ein (Linux):

strace -ff -o strace-log.txt anwendung

oder debuggen

gdb anwendung coredump-file

der letzte ausgeführte Befehl ist interessant. Das ist aber alles etwas mühselig...

 

[bygones]

Tritt der Fehler immer im Zusammenhang mit geforkten JUnit Tests aus dem ANT auf?

ja tut es, aber nicht immer. Manche Tests die in Ant geforkt werden laufen durch, manche dann nicht... (der ant befehl forkt alle tests die laufen sollen)

* Falls mehrere Javas installiert sind, versuche mal alle bis auf das letzte installierte zu entfernen. Bei uns gab es ähnliche Probleme, weil mehrere JRE's (OpenJDK und Sun) manuell installiert waren (32bit und 64bit teilten sich dann dieselben .so-Dateien).

es wurden keine "installiert". Es liegen versch. Java Versionen (alle von Sun) nebeneinander. Über JAVA_HOME wird dann die entsprechende vom build gezogen

* Ansonsten gab es bei uns Probleme mit Java-Maschinen, die nicht von Sun waren und unregelmäßig SIGSEGV's schmissen (Diablo Java und OpenJDK machten da Probleme).

wie gesagt - alle von Oracle

 

[FArt]

Schau dir mal die Kommandozeile an, die der ANT generiert. Auch die VM Parameter, u.U. ist das etwas ganz triviales wie zu wenig Speicher oder so....
Erstelle Logging für den geforkten Prozess.

 

[bygones]

danke werde ich untersuchen.

ich versteh jedoch noch nicht so ganz, warum überhaupt geforkt wird.... im netz findet man widersprüchliches es, ob und wann man forken sollte.

Und wenn überhaupt, so ist die default einstellung "perTest" schon übel find ich... wenn sollte once doch reichen ?

bygones... mal ohne forken n build laufen lassen.

 

[bygones]

interessant... ohne fork fliegt eine PermGen outofmemory...

kann es sein, dass der gespawnte prozess zu wenig speicher hatte (ich geb keinen besonderen an und den vom eigentlich ant prozess wird er wahr. nicht mitbekommen) und er nicht mit einem PermGen rausgeht sondern eben mit dem fatal error ?!

 

[FArt]

interessant... ohne fork fliegt eine PermGen outofmemory...

kann es sein, dass der gespawnte prozess zu wenig speicher hatte (ich geb keinen besonderen an und den vom eigentlich ant prozess wird er wahr. nicht mitbekommen) und er nicht mit einem PermGen rausgeht sondern eben mit dem fatal error ?!

Ja, das hatte ich ja schon vermutet. Allerdings kommt so eine Exception natürlich ohne forken u.U. viel früher wenn nicht geforkt wird.
Schließlich werden alle Klassen in die VM des ANT Prozesses geladen. Wenn das sehr viele sind, geht sehr schnell die PermGen aus oder auch der Heap.

Bei vielen Tests sollte man forken, da dessen Ressourcen nicht den ANT Prozess belasten. Du brauchst aber dringend Infos und Logging der geforkten Prozesse! Du kannst ja (nur mal zum Spaß) den Heap und die PermGen aller geforkten Prozesse auf "sehr hoch" setzen, nur um u.U. schnell herauszufinden, ob das die richtige Schraube zum drehen ist.

 

[bygones]

jo mit nicht forken waren dann auch ein paar tests die fehlschlugen ....

wir haben einmal nun eine 32bit VM am testen und einmal eine 64bit mit fork="true" formode="once". Damit sind gerade beide builds erfolgreich durchgelaufen. Wir werden die Projekte die nächsten Tage forsiert bauen lassen um zu schauen ob dies nun weiterhin klappt oder nur ein Glückstreffer war