JVM verabschiedet sich beim laden einer DLL

normaler_spinner

Erfahrenes Mitglied
Hallo zusammen,

ich hab hier nen kleinen Problem welches ich nicht ganz nachvollziehen kann. Für mein Programm muss ich eine DLL einbinden. Um darauf zugreifen zu können habe ich mir eine eigene DLL erstellt die ich dann über das JNI ansprechen kann.
Seltsamerweise, je nach dem wo ich die DLL einbinde terminiert sich die JVM.

Mal ein Beispiel:
Code:
	/**
	 * 
	 * Constructor
	 */
	public Controller(){
		System.loadLibrary("SPSReader"); // Hier gehts nicht

		getMainFrame();
		//System.loadLibrary("SPSReader"); // Hier gehts

	}

Das ist die Trauernachricht zum Absterben
Code:
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  EXCEPTION_FLT_STACK_CHECK (0xc0000092) at pc=0x0090d069, pid=176, tid=3380
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode)
# Problematic frame:
# v  ~RuntimeStub::resolve_virtual_call
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

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

Current thread (0x00386000):  JavaThread "main" [_thread_in_Java, id=3380]

siginfo: ExceptionCode=0xc0000092, ExceptionInformation=0x00000000 0x003ee4b4 

Registers:
EAX=0xffffffff, EBX=0x000008c5, ECX=0x0298df58, EDX=0x029908b8
ESP=0x003ee448, EBP=0x003ee558, ESI=0x0298df58, EDI=0x000008c5
EIP=0x0090d069, EFLAGS=0x00010216

Top of Stack: (sp=0x003ee448)
0x003ee448:   ffff1372 ffff0020 ffffffff 6d983a27
0x003ee458:   011c001b 0acdf770 ffff0023 7c921596
0x003ee468:   7c9206eb 2bf02b80 f8f80036 00000007
0x003ee478:   00000004 00360748 f8d00000 f8d40007
0x003ee488:   fb140007 7c920738 ffffffff 00000732
0x003ee498:   5be00000 4005c805 00000000 80000000
0x003ee4a8:   00004002 00000000 3ffd8000 003ee4fc
0x003ee4b8:   003ee514 00000000 003ee50c 00000000 

Instructions: (pc=0x0090d069)
0x0090d059:   00 00 83 ec 6c dd 34 24 9b dd 24 24 dd 5c 24 6c
0x0090d069:   dd 5c 24 74 dd 5c 24 7c dd 9c 24 84 00 00 00 dd 


Stack: [0x003a0000,0x003f0000),  sp=0x003ee448,  free space=313k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v  ~RuntimeStub::resolve_virtual_call
J  java.util.Properties$LineReader.readLine()I
j  java.util.Properties.load0(Ljava/util/Properties$LineReader;)V+7
j  java.util.Properties.load(Ljava/io/InputStream;)V+10
j  java.util.logging.LogManager.readConfiguration(Ljava/io/InputStream;)V+13
j  java.util.logging.LogManager.readConfiguration()V+181
j  java.util.logging.LogManager$2.run()Ljava/lang/Object;+4
v  ~StubRoutines::call_stub


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

Java Threads: ( => current thread )
  0x0aa8b000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=2372]
  0x0aa86400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=3000]
  0x0aa85000 JavaThread "Attach Listener" daemon [_thread_blocked, id=2204]
  0x0aa84400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=280]
  0x0aa76800 JavaThread "Finalizer" daemon [_thread_blocked, id=324]
  0x0aa72000 JavaThread "Reference Handler" daemon [_thread_blocked, id=252]
=>0x00386000 JavaThread "main" [_thread_in_Java, id=3380]

Other Threads:
  0x0aa6f000 VMThread [id=288]
  0x0aaa5c00 WatcherThread [id=4072]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 def new generation   total 960K, used 220K [0x02960000, 0x02a60000, 0x02e40000)
  eden
[error occurred during error reporting, step 190, id 0xc0000092]

Dynamic libraries:
0x00400000 - 0x00423000 	C:\Programme\Java\jre1.6.0\bin\javaw.exe
0x7c910000 - 0x7c9c7000 	C:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c906000 	C:\WINDOWS\system32\kernel32.dll
0x77da0000 - 0x77e4a000 	C:\WINDOWS\system32\ADVAPI32.dll
0x77e50000 - 0x77ee1000 	C:\WINDOWS\system32\RPCRT4.dll
0x7e360000 - 0x7e3f0000 	C:\WINDOWS\system32\USER32.dll
0x77ef0000 - 0x77f37000 	C:\WINDOWS\system32\GDI32.dll
0x76330000 - 0x7634d000 	C:\WINDOWS\system32\IMM32.DLL
0x7c340000 - 0x7c396000 	C:\Programme\Java\jre1.6.0\bin\msvcr71.dll
0x6d7c0000 - 0x6da07000 	C:\Programme\Java\jre1.6.0\bin\client\jvm.dll
0x76af0000 - 0x76b1e000 	C:\WINDOWS\system32\WINMM.dll
0x6d310000 - 0x6d318000 	C:\Programme\Java\jre1.6.0\bin\hpi.dll
0x76bb0000 - 0x76bbb000 	C:\WINDOWS\system32\PSAPI.DLL
0x6d770000 - 0x6d77c000 	C:\Programme\Java\jre1.6.0\bin\verify.dll
0x6d3b0000 - 0x6d3cf000 	C:\Programme\Java\jre1.6.0\bin\java.dll
0x6d7b0000 - 0x6d7bf000 	C:\Programme\Java\jre1.6.0\bin\zip.dll
0x0ad80000 - 0x0ad89000 	D:\EclipseWorkspace\TestCase\SPSReader.dll
0x10000000 - 0x10059000 	D:\EclipseWorkspace\TestCase\AGLINK40.DLL
0x71a10000 - 0x71a27000 	C:\WINDOWS\system32\WS2_32.DLL
0x77be0000 - 0x77c38000 	C:\WINDOWS\system32\msvcrt.dll
0x71a00000 - 0x71a08000 	C:\WINDOWS\system32\WS2HELP.dll
0x32700000 - 0x327a9000 	C:\WINDOWS\system32\CC3270MT.DLL
0x770f0000 - 0x7717c000 	C:\WINDOWS\system32\OLEAUT32.DLL
0x774b0000 - 0x775ed000 	C:\WINDOWS\system32\ole32.dll

VM Arguments:
java_command: Main
Launcher Type: SUN_STANDARD

Environment Variables:
PATH=C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\;C:\Programme\Borland\BDS\4.0\Bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\ATI Technologies\ATI Control Panel;C:\Programme\Qt\bin;C:\MinGW\bin;C:\Programme\Gemeinsame Dateien\GTK\2.0\bin;C:\Dokumente und Einstellungen\Jens\Eigene Dateien\Borland Studio-Projekte\bpl;C:\Programme\Java\jdk1.6.0\bin
USERNAME=Jens
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 10, AuthenticAMD



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

OS: Windows XP Build 2600 Service Pack 2

CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2, mmxext, 3dnowext, 3dnow

Memory: 4k page, physical 522736k(67784k free), swap 1275596k(669204k free)

vm_info: Java HotSpot(TM) Client VM (1.6.0-b105) for windows-x86, built on Nov 29 2006 00:48:48 by "java_re" with unknown MS VC++:1310

Ich könnte ja mit dem Workaround leben die DLL an einer anderen Stelle einzubinden, jedoch wenn ich mein Projekt in verschiedene Packages aufteile geht selbst das nicht mehr.

Wäre schön wenn jemand dafür einen Lösungsansatz hätte.
 
Zuletzt bearbeitet:
Hallo,

was machst du denn in deiner DLL? Greifst du im JNI_OnLoad eventuell auf noch nicht vorhandene Resourcen zu? Falls du auf den JFrame zugreifst... denk dran dass das handle auf dem OS erst dann realisiert wird, wenn dieser angezeigt wird...

Gruß Tom
 
Hallo Thomas,

kann dir jetzt nicht ganz folgen. Ich gehe davon aus, das beim Laden die DLL auch wirklich nur geladen wird und kein Code aus der DLL ausgeführt wird. Gebraucht wird sie erst später im Programm um auf eine SPS zuzugreifen. Hat aber nichts mit den anderen Komponenten der View zu tun. Hatte auch schon versucht das Laden der DLL auf den Zeitpunkt zu verschieben an dem sie wirklich gebraucht wird, leider ebenfalls ohne Erfolg. Hatte mich schon mit Sun in Verbindung gesetzt.
Folgende Antwort bekommen
Code:
Thank you for reporting this issue. 

I have been analyzing your bug report and do recognize that there could be a possible problem that merits further investigation. However, I would appreciate more information to create a new bug. 

In addition to the information already provided, please include the following: 

- Complete source code of an executable test case . 
- Exact steps to run the test case and reproduce the crash.
- Additional configuration information that may be relevant.

To investigate this issue, we need to be able to reproduce the problem ourselves. In addition, a small test case will speed the investigation by reducing the possible causes of the behavior.

Hotspot crashes are difficult to debug and any information in this regard will be a great help.

We greatly appreciate your efforts in identifying areas in the Java Standard Edition where we can improve upon and I would request you to continue doing so.

Naja, würde denen ja gerne ein Beispiel zum testen geben, mit den Quelltext alleine ist denen aber sicherlich nicht geholfen. Bräuchten ja auch die DLL, die wiederum benötigt aber dann auch eine SPS-spezifische DLL deren Quelltext ich ja nicht haben kann.
Man hat ja nicht mal die Möglichkeit denen nen kleines Jar zu schicken :confused:
 
Hallo,

kann dir jetzt nicht ganz folgen. Ich gehe davon aus, das beim Laden die DLL auch wirklich nur geladen wird und kein Code aus der DLL ausgeführt wird.
Okay.. die dll die du geschrieben hast macht das vielleicht nicht... und was ist mit der/den anderen (davon abhängigen)? ;-)

Gruß Tom
 
Die andere hat so rein gar nichts mit Java am Hut. Meine DLL dient rein dazu um über das JNI auf die SPS-DLL zuzugreifen. Die ist dann einfach nur dafür da, Daten aus der SPS zu lesen oder zu schreiben.
 
Hallo,

was macht denn die Methode getMainFrame()? Erstellt die etwa das Hauptfenster der Anwendung? (dann sollte sie wohl eher openAndRunMainFrame() .. heißen).
Wie gesagt du musst dich Fragen, was nach diesem Methoden Aufruf ist als davor... (wo's ja nicht geht) Da ich deinen Code nicht kenne kann ich nur von dem Mutmaßen was ich sehe... und dann würde ich sagen, dass eben nach der Methode die Oberfläche / das Hauptfenster Initialisiert ist und angezeigt wird. Weiterhin kann es sein, durch das sichtbar machen des Hauptfensters wird in Windows des entsprechende Native Peer erzeugt und die Resourcen allokiert. Außerdem werden sicherlich noch einige Windows Dlls nachgeladen, die davor(!) nicht geladen waren... vielleicht liegt hier ja der Hase im Pfeffer...

Gruß Tom
 
Ja stimmt, nicht anderes macht getMainFrame(). Hier wird das Anwendungsfenster initialisiert und geöffnet. Aber selbst wenn ich den onLoad an eine Stelle verschiebe, nachdem der Frame schon lange aufgebaut ist und dann beispielsweise erst bei einem Aufruf über einen Menüpunkt geladen wird, kracht es. Daher gehe ich davon aus, dass es daran nicht liegen kann.
 
Nein, keine Einschränkungen. Ich teste gerade mal ob es an einer Einstellung vom Borland C++ Builder liegt. In 10 Minuten weiß ich mehr. Da gabs ne Einstellung irgendwo wie sich die DLL beim Laden zu verhalten hat, bezüglich der Speicherverwaltung.
 
Zurück