JVA verursacht EXCEPTION_ACCESS_VIOLATION?
Mein Java UI unexpectly beendet und warf einen hs_err_pid
- Datei. Die Datei sagt "Der Absturz passiert außerhalb der Java Virtual Machine in native code." JVA ist die einzige native-code, den wir verwenden. Kennt jemand bekannte Probleme oder bugs mit jedem JVA-version, die den Fehler verursachen. Ich habe einige der Inhalte aus dem Fehler-Datei unten.
An unexpected error has been detected by Java Runtime Environment:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d02bcbd, pid=312, tid=3616
Java VM: Java HotSpot(TM) Client VM (11.0-b16 mixed mode, sharing windows-x86)<br>
Problematic frame:
C [awt.dll+0x2bcbd]
If you would like to submit a bug report, please visit:
http://java.sun.com/webapps/bugreport/crash.jsp
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.
Current thread (0x02acf000): JavaThread "AWT-Windows" daemon [_thread_in_native, id=3616, stack(0x02eb0000,0x02f00000)]
siginfo: ExceptionCode=0xc0000005, writing address 0xe2789280
Registers:
EAX=0x234f099c, EBX=0x00001400, ECX=0x00000100, EDX=0xe2789280
ESP=0x02eff4a4, EBP=0x00000400, ESI=0x234f099c, EDI=0xe2789280
EIP=0x6d02bcbd, EFLAGS=0x00010206
Top of Stack: (sp=0x02eff4a4)
0x02eff4a4: 02eff500 00000100 02eff584 00000100
0x02eff4b4: 6d0a5697 00000400 00000400 00000100
0x02eff4c4: 00000100 02eff700 02eff500 00000000
0x02eff4d4: 00000000 00000100 041ac3a0 00000100
0x02eff4e4: 00182620 00000400 e2789280 00000000
0x02eff4f4: 00000000 00000100 00000100 00000000
0x02eff504: 00000000 00000100 00000100 00000000
0x02eff514: 00000000 00000004 00000400 00000000
Instructions: (pc=0x6d02bcbd)
0x6d02bcad: 00 00 00 8b 4c 24 14 8b e9 c1 e9 02 8b f0 8b fa
0x6d02bcbd: f3 a5 8b cd 83 e1 03 f3 a4 8b 74 24 18 8b 4c 24
Stack: [0x02eb0000,0x02f00000], sp=0x02eff4a4, free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [awt.dll+0x2bcbd]
[error occurred during error reporting (printing native stack), id 0xc0000005]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j sun.awt.windows.WToolkit.eventLoop()V+0
j sun.awt.windows.WToolkit.run()V+69
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich nur Treffer, die gleichen Fehler, es ist apppearantly ein bug in der neuen Direct3d beschleunigte Java2d-Funktionalität mit 1.6.0_11 das geschieht bei Maschinen mit geringen video-ram.
Wenn Sie beginnen, Ihre app mit -Dsun.java2d.d3d=false sollte es wieder funktionieren.
Die Sonne bug-tracking das ist die folgende: http://bugs.sun.com/view_bug.do?bug_id=6788497
Urteilen:
(an welchem Punkt der stack-trace offenbar gesprengt) Sie könnte auf einen bug in der AWT-Bibliothek.
Nur weil die nur bit-native-code, den Sie wissentlich verwendet wird JNI/whatever bedeutet nicht, dass ein Absturz wie bei Euch verwandt, um es im Ort oder in der Zeit. Es gibt alle möglichen native Unterstützung verwendet schweigend in einer bestimmten JVM/Ausführung, und ich war auf einmal bekommen bizarre Abstürze am Ende von Korruption, was passiert war, viel früher und von der JVM selbst.
In meinem Fall war ich Suche nach spannenden bugs im Gewinde concurrent GC auf meine glänzende neue multi-CPU (Niagara) das Feld, das verlassen wurde, alle Arten von Bomben, die warten, um aus und ich hatte keine nicht-JDK native code in meine app überhaupt.
Wenn die Sonne GC-team repariert Ihre Fehler (und sehr freundlicherweise mich mit einem test-bootleg-VM) meine Fragen verdampft (gut, nach einer Runde oder zwei, versteht sich).
Rgds
Damon
Den Sie getroffen haben eine Zugriffsverletzung, was bedeutet, dass einige Codes versucht, Zugriff auf eine Adresse, die es nicht erlaubt, oft, weil es nicht jede Erinnerung an die darauf angegebene Adresse. Die stacktrace-Punkte zu dem Speicherort, stolperte über das problem, die kann oder nicht werden die Quelle des Problems. Menschen, die manchmal vergessen, über diese, wenn Sie sprechen von native code, auch wenn Sie sich dessen bewusst sind sonst.
Ich verwendet habe, JVA, hatte aber nie ein Problem mit es. Wenn es eine Zugriffsverletzung, es war meine Schuld. Hier sind ein paar einfache Ratschläge.
Stellen Sie sicher, dass Ihre Maschine ist physikalisch sound. Testen Sie Ihr Gedächtnis mit Memtest86+. Es gibt keine Verwendung Jagd-ein software-Fehler ist, wenn es ein hardware-problem.
Blick auf den code mit JNA. Werden Sie sich bewusst, dass, selbst wenn die Aufrufe in der Java look-unauffällig, schreiben Sie low-level-code, der kann mit Chaos nichts. Durchaus möglich, den code mit der JVA-etwas falsch macht und verdirbt den Speicher. Zum Beispiel, stellen Sie sicher, die korrekte Aufrufkonvention und Daten ausgerichtet ist. Wenn Sie Zweifel haben, Holen Sie sich jemanden, der bequem mit C (oder, allgemeiner, low-level-Sachen), um Ihnen zu helfen.
Nicht ganz andere Faktoren auszuschließen. Es kann gut sein, dass Sie hit ein JVM-Fehler oder so etwas, aber vorsichtig sein, wie wahrscheinlich das ist. Wenn Sie hören hoofbeats, denken Pferde, nicht zebras.