# JVM Core Dump auf Solaris?!



## Haymaker84 (2. Mai 2010)

Hi,

es gibt ein Problem mit einer Anwendung, die wir gerade abschliessen wollen.

Diese wurde mit Java 1.5 und der Oracle Dev Suite 10g (JDeveloper) / ADF Framework entwickelt. Unter Win XP.
Diese nimmt Mitteilungen als Textfile entgegen und schiebt sie in die DB.

In der Entwicklungsumgebung schafft es das Programm auch ohne Probleme (~20.000 Mitteilungen).

Allerdings wollten wir die Anwendung mal auf das Produktionssystem deployen, welches ein Solaris-System ist.
Hierbei kommt es sporadisch (mal nach 2 Mitteilungen, mal nach 6.000, mal gar nicht....) zu technischen Abbrüchen einer mir bis Dato unbekannten Art - einem JVM Core Dump. Das Programm lässt sich danach gleich wieder starten und verarbeitet die bezügliche Mitteilung ohne Probleme - ist also aus meiner Sicht schwer zu reproduzieren!
Kurze recherchen haben meinen Verdacht bestätigt, dass es sich um einen Speicherabzug handelt.

Damit steh ich jetzt aber wie der Sprichwörtliche Ochs vorm' Tor, denn ich weiss mit dem Ding nicht wirklich was anzufangen.
Von natur aus ist dieses File ja weniger auskunftsfreudig als ein Stacktrace.
Wobei ich mir auch nicht vorstellen kann, was ich SO falsch gemacht hätte, das es nicht durch einen Stacktrace auszudrücken wäre...

Ich hab auch die Befürchtung, dass es etwas Linux/Unix spezifisches sein Kann (Rechte etc.), wovon ich echt keinen Plan habe.
Google hat mich bis jetzt auch sehr sparsam mit Infos zu dem Thema gesegnet.

Also meine Fragen dazu:
- Warum kommt statt nem guten Stacktrace ein Speicherabzug?
- Wie wertet man den Dump aus? garnicht? per Hand? Toolgestützt?
- sind zwischen den Windows und Solaris JVMs elementare Unterschiede zu Bedenken?

Gruß,
Henning


----------



## JohannisderKaeufer (2. Mai 2010)

Wurde die Anwendung auf dem Produktivsystem compiliert oder dort nur deployed?


----------



## Haymaker84 (2. Mai 2010)

nur deployed, aber aufgrund der vielbeschworenen Plattformunabhängigkeit sollte das doch eigentlich kein Thema sein?!


----------



## FArt (3. Mai 2010)

In der Regel weist so etwas auf einen Fehler in der VM oder in den verwendeten nativen Bibliotheken hin (Treiber?). Poste mal den den Dump, da müssten Hinweise darauf zu finden sein


----------



## Haymaker84 (3. Mai 2010)

okay, ich wurde eben darauf aufmerksam gemacht, dass neben des reinen Speicher-Abzuges auch noch eine Infodatei erstellt wird. Die Poste ich jetzt mal hier. Der Dump selbst sind ja nur 275 MB Schmierzeichen...


```
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xfdcf4cc0, pid=12512, tid=12
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# V  [libjvm.so+0xf4cc0]
#

---------------  T H R E A D  ---------------

Current thread (0x00146d30):  JavaThread "CompilerThread1" daemon [_thread_in_native, id=12]

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000004

Registers:
 O0=0x00004488 O1=0x00000000 O2=0x00000000 O3=0x00000000
 O4=0x00000000 O5=0x00001122 O6=0xb43805c0 O7=0x00002000
 G1=0x00004488 G2=0x008bda60 G3=0x0097a230 G4=0x00000000
 G5=0x003a66f0 G6=0xf8815d10 G7=0xb4381d98 Y=0x00000000
 PC=0xfdcf4cc0 nPC=0xfdcf4cc4


Top of Stack: (sp=0xb43805c0)
0xb43805c0:   b438081c 00d673cc 003a66f0 00000000
0xb43805d0:   008bda60 00000000 00002000 003a66f0
0xb43805e0:   b438080c 00a1fcec 0074eb3c 00000000
0xb43805f0:   003a66f0 008bda60 b4380620 fde06600
0xb4380600:   b43811b0 00001332 b4380680 fde044a0
0xb4380610:   00000000 fe3f5d80 00000000 00000000
0xb4380620:   00000000 ffffffff 00000001 b438081c
0xb4380630:   b4380844 0074eb3c 00000001 00000004 

Instructions: (pc=0xfdcf4cc0)
0xfdcf4cb0:   f6 02 20 1c c6 06 20 58 89 2e e0 02 f6 00 c0 04
0xfdcf4cc0:   d2 06 e0 04 d0 02 60 00 80 a2 20 00 32 40 00 11 

Stack: [0xb4302000,0xb4381d98),  sp=0xb43805c0,  free space=505k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xf4cc0]
V  [libjvm.so+0x206608]
V  [libjvm.so+0x2047ec]
V  [libjvm.so+0x27fdac]
V  [libjvm.so+0x282748]
V  [libjvm.so+0x278700]
V  [libjvm.so+0x2793bc]
V  [libjvm.so+0x335f28]
V  [libjvm.so+0x2de2a4]
V  [libjvm.so+0x664248]


Current CompileTask:
opto:1084      oracle.sql.NUMBER.toBytes(Ljava/lang/String;I)[B (1034 bytes)


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x00ae0ee0 JavaThread "Timer-1" daemon [_thread_blocked, id=16]
  0x004e2638 JavaThread "Timer-0" daemon [_thread_blocked, id=15]
  0x00147de0 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=13]
=>0x00146d30 JavaThread "CompilerThread1" daemon [_thread_in_native, id=12]
  0x00145e20 JavaThread "CompilerThread0" daemon [_thread_blocked, id=11]
  0x00144fb0 JavaThread "AdapterThread" daemon [_thread_blocked, id=10]
  0x00144248 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=9]
  0x00139b50 JavaThread "Finalizer" daemon [_thread_blocked, id=8]
  0x00139750 JavaThread "Reference Handler" daemon [_thread_blocked, id=7]
  0x000373b8 JavaThread "main" [_thread_in_Java, id=1]

Other Threads:
  0x00135ef8 VMThread [id=6]
  0x0014a078 WatcherThread [id=14]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 PSYoungGen      total 37376K, used 10316K [0xe2eb0000, 0xe5540000, 0xf8400000)
  eden space 36032K, 25% used [0xe2eb0000,0xe37bd7a8,0xe51e0000)
  from space 1344K, 77% used [0xe53f0000,0xe54f5bf8,0xe5540000)
  to   space 1728K, 0% used [0xe51e0000,0xe51e0000,0xe5390000)
 PSOldGen        total 143360K, used 48424K [0xb8400000, 0xc1000000, 0xe2eb0000)
  object space 143360K, 33% used [0xb8400000,0xbb34a3d0,0xc1000000)
 PSPermGen       total 41472K, used 20122K [0xb4400000, 0xb6c80000, 0xb8400000)
  object space 41472K, 48% used [0xb4400000,0xb57a6bc8,0xb6c80000)

Dynamic libraries:
0x00010000 	/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/bin/java
0xff360000 	/usr/lib/libthread.so.1
0xff350000 	/usr/lib/libdl.so.1
0xff280000 	/usr/lib/libc.so.1
0xff3a0000 	/usr/platform/FJSV,GPUZC-L/lib/libc_psr.so.1
0xfdc00000 	/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc/server/libjvm.so
0xff220000 	/usr/lib/libsocket.so.1
0xff200000 	/usr/lib/libsched.so.1
0xff1d0000 	/usr/lib/libCrun.so.1
0xff180000 	/usr/lib/libm.so.1
0xff080000 	/usr/lib/libnsl.so.1
0xff150000 	/usr/lib/libmp.so.2
0xff040000 	/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc/native_threads/libhpi.so
0xfe7d0000 	/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc/libverify.so
0xfe790000 	/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc/libjava.so
0xfe760000 	/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc/libzip.so
0xfe5e0000 	/usr/lib/locale/de_DE.ISO8859-15/de_DE.ISO8859-15.so.2
0xfaba0000 	/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc/libnet.so
0xfa9c0000 	/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc/libmanagement.so
0xb2b80000 	/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc/libawt.so
0xb2a00000 	/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc/libmlib_image.so
0xfa9a0000 	/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc/headless/libmawt.so

VM Arguments:
jvm_args: -DRzKennung=17085 -DEingabePfad=daten17085 -DEingabeDatei=SD.VMI.17085.EIN -DAusgabePfad=daten17085/ -DAusgabeDateiDruck=MitUebAusgabe_RZ -DAusgabeDateiFehler=Fehler -DAusgabeDateiSkf=SKF -DAusgabeDateiTechProt=TP -DAusgabeDateiGesperrte=GesperrteMitteilungen -DAusgabeDateiFehlerstatistik=DZB8 -DAusgabeDateiLogging=log.txt -DAusgabeDateiLetzteMitteilung=letzteMitteilung.txt -DLogLevel=ALL -DDbSchema=TEST
java_command: mitueb.jar
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/bin
PATH=/usr/bin:/usr/ucb:/etc:.:/opt/SMAW/bin:/opt/SMAW/sbin
LD_LIBRARY_PATH=/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc/server:/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/lib/sparc:/opt/SMAW/SMAWj2rt/jre/solaris/jre1.5.0_06/../lib/sparc:/opt/SMAW/lib
SHELL=/bin/sh
HOSTTYPE=sparc
OSTYPE=solaris
MACHTYPE=sparc-sun-solaris

Signal Handlers:
SIGSEGV: [libjvm.so+0x6f0ca8], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGBUS: [libjvm.so+0x6f0ca8], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGFPE: [libjvm.so+0x275d94], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGPIPE: [libjvm.so+0x275d94], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGILL: [libjvm.so+0x275d94], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGUSR1: [libjvm.so+0x666744], sa_mask[0]=0x00008000, sa_flags=0x00000008
SIGUSR2: [libjvm.so+0x275d94], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGHUP: [libjvm.so+0x665424], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGINT: [libjvm.so+0x665424], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGQUIT: [libjvm.so+0x665424], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGTERM: [libjvm.so+0x665424], sa_mask[0]=0xffbffeff, sa_flags=0x00000004


---------------  S Y S T E M  ---------------

OS:                Solaris 8 2/02 Fujitsu_3 s28s_u7fjsv3wos_04 SPARC
           Copyright 2002 Sun Microsystems, Inc.  All Rights Reserved.
                           Assembled 08 December 2002

uname:SunOS 5.8 Generic_117350-43 sun4us  (T1 libthread)
rlimit: STACK 8192k, CORE infinity, NOFILE 1024, AS infinity
load average:1,56 1,47 1,39

CPU:total 2 has_v8, has_v9, has_vis1, has_vis2, is_ultra3

Memory: 8k page, physical 8388608k(6145568k free)

vm_info: Java HotSpot(TM) Server VM (1.5.0_06-b05) for solaris-sparc, built on Nov 10 2005 11:24:16 by unknown with unknown Workshop:0x550
```


----------



## maki (3. Mai 2010)

Es ist vollkommen normal dass man die App nicht dort baut wo sie deployed wird 

Mit VisualVM kann man einen Core Dump einlesen & analysieren.


----------



## FArt (3. Mai 2010)

Was ist das für ein DB-Treiber? Gibt es einen neueren? Kann man mal einen anderen versuchen (z.B. anstatt JDBC den ODBC Treiber oder umgekehrt).

1. Vermutung: der JIT-Compiler versucht eine Klasse zu optimieren und fällt dabei auf die Nase. Man könnte den JIT Compiler mal ausgeben lassen was er so treibt oder auf gut Glück gleich mal die Klasse oracle.sql.NUMBER von einer Optimierung ausnehmen.
Chapter 8 Continued: Performance Features and Tools


----------



## Haymaker84 (3. Mai 2010)

maki hat gesagt.:


> VisualVM



leider haben wir kein Java 1.6 ;(


----------



## maki (3. Mai 2010)

Gra kein Java 1.6, auhc nicht bei dir auf der Entwickelr Maschine? (Java 5 wird ja nicht mehr unterstützt)
Da gab es auch ein Tool (mindestens) für Java 5, fällt mir aber gerade nciht ein...


----------



## FArt (3. Mai 2010)

Haymaker84 hat gesagt.:


> leider haben wir kein Java 1.6 ;(


Das ist nicht nötig. Weder für den Tausch des DB Treibers noch für das Ausnehmen von Klassen aus der Optimierung des Laufzeitcompilers ;-)
Funktioniert auch mit 5 bzw. mit neueren 1.4ern ....


----------



## Haymaker84 (3. Mai 2010)

FArt hat gesagt.:


> Was ist das für ein DB-Treiber?



Wir hatten den ojdbc14.jar in gebrauch. Dann hatten wir das Problem, dass das Produktionssystem gepatcht wurde und der alte Treiber inkompatibel wurde. Dann wollten wir unsere Entwicklungsumgebung auf die 1.6er Version vom JDeveloper migrieren, das funktioniert bei unserem Workspace nicht - es gibt kryptische Fehler.
Aufgrund unserer Projektsituation müssen solche Probleme hinten an. Deswegen haben wir per Hand den Treiber ojdbc5.jar eingebaut, zu testzwecken. Das hat Funktioniert und wir dachten damit könnten wir die Lebensdauer unserer IDE künstlich verlängern... (bis zur nächsten Projektstufe)

Ich hab grad mal den JIT komplett ausgestellt. Es läuft zwar langsamer, dafür hat er bisher keinen Dump produziert. Wenn das klappt, kann man ihn ja wieder an machen und gezielt Klassen ausschliessen.

Aber schon mal zwischendurch schon mal vielen Dank - sehr kompetenten Rat, den mal hier bekommt!


----------



## FArt (3. Mai 2010)

Haymaker84 hat gesagt.:


> Wir hatten den ojdbc14.jar in gebrauch. Dann hatten wir das Problem, dass das Produktionssystem gepatcht wurde und der alte Treiber inkompatibel wurde. Dann wollten wir unsere Entwicklungsumgebung auf die 1.6er Version vom JDeveloper migrieren, das funktioniert bei unserem Workspace nicht - es gibt kryptische Fehler.
> Aufgrund unserer Projektsituation müssen solche Probleme hinten an. Deswegen haben wir per Hand den Treiber ojdbc5.jar eingebaut, zu testzwecken. Das hat Funktioniert und wir dachten damit könnten wir die Lebensdauer unserer IDE künstlich verlängern... (bis zur nächsten Projektstufe)


Sehr interessante und hinweisgebende Information, wenn es um plötzliche Abstürze der VM geht ;-)

Es kann auch sein, dass es sich um ein Synchronisationsproblem im Treiber oder in einer nativen Bibliothek handelt. Das Ausschalten des JIT-Compilers verlangsamt dann die Ausführung, der Fehler tritt u.U. (zufällig) nicht mehr auf weil sich das Laufzeitverhalten verändert hat, das ist aber keine Lösung...

Ob die Einbindung des ojdb5-Treibers "funktioniert" hat ist fraglich... evtl. ist genau das das Problem...*G*


----------



## Haymaker84 (3. Mai 2010)

FArt hat gesagt.:


> Was ist das für ein DB-Treiber? Gibt es einen neueren? Kann man mal einen anderen versuchen (z.B. anstatt JDBC den ODBC Treiber oder umgekehrt).





FArt hat gesagt.:


> Ob die Einbindung des ojdb5-Treibers "funktioniert" hat ist fraglich... evtl. ist genau das das Problem...*G*



Nun ja, mit deinem ersteren Post hast du ja eigentlich den selben Gedankengang verfolgt wie wir damals... (Es funktioniert nicht - erstmal nen neuen DB Treiber versuchen)

Beim letzteren scheinst du den Gedanken irgendwie zu kritisieren.
Oder bin ich das Handwerklich falsch angegangen?

???:L


----------



## FArt (3. Mai 2010)

> Oder bin ich das Handwerklich falsch angegangen?


Nein. Oder ja?
Das lässt sich aus meiner Position absolut nicht beurteilen. So lange ich mich im Rahmen der Spezifiaktion bewege sollte ich beliebig variieren können.
Prinzipiell kann man sich aber mit Patches und Versionssprüngen auf dünnes Eis begeben. Es wird halt durch neue Versionen nicht zwangsläufig alles besser.
Wenn etwas nicht so funktioniert wie erwartet, sind diese Stellen aber auch die ersten Verdächtigen.

Bei meinen ersten Anmerkungen ging es auf jeden Fall erst mal darum, einen potentiell Schuldigen auszumachen.

Die Erfahrung zeigt aber, dass (unbekannte) Fehler in der VM oder in nativen Libraries (die in der Regel recht abgehangen sind) relativ selten vorkommen und man gut beraten ist, bei Problemen die eigenen "Variationen" des Standards zu verdächtigen.

Nichtsdestotrotz: wir haben bisher noch jeden Oracle-Treiber (wenn auch JDBC) gepatcht ;-)


----------



## Haymaker84 (5. Mai 2010)

ich habe jetzt mal Testweise in meinem Shell-Script die Umgebungsvariable

export _JIT_ARGS="exclude(oracle.sql.NUMBER)"

eingefügt, da der JIT-Kompiler in dem Info-File zum Core-Dump diese ja anscheinend moniert hat.
Danach habe ich die letzten Tage Lasttests durchgeführt, dabei wurden über 60.000 Eingabesätze in verschieden Blockgrössen verarbeitet, ohne das es Probleme gab.
Was ja schonmal deutlich stabiler klingt!

Bleibt nur die Vermutung, dass der neuere DB-Driver wirklich nicht mit seinen älteren Bibliotheken klar kommt. In der nächsten Projektphase müssen wir wohl schleunigst migrieren ... 

Ich bedanke mich nochmals bei den Threadteilnehmern für schnelle und kompetente Hilfe, insbesondere bei FArt! :applaus:


----------

