AttachCurrentThread Crash

[Markus KARG]

Steve Bohne wrote:
> Very interesting project.
Thank you. In fact, the target of the project is to provide a general 
solution that allows to write Shell Extensions in pure Java (without 
further knowledge of the native desktop API), and add it to either JDIC 
and / or OpenJDK. The Java peer of that shall be a simple API that can 
not only be implemented for Windows (as I do it right now) but hopefully 
will be implemented by others (or Sun?) for KDE, Gnome, MacOS etc. 
Integrating Java deeply into the desktop is one of my key interests and 
I wonder why there is not yet something like that already.
> When your DLL gets unloaded, does jvm.dll also get unloaded? As you 
> mentioned, if jvm.dll is getting loaded twice, even sequentially, this 
> might cause problems.  (Yes, it's a known limitation of embedding a 
> JVM in another application. Don't know of any current activity to work 
> on a solution for this issue, but submitted patches will be carefully 
> considered. :))
Unfortunately I am not understanding the jvm.dll source code well enough 
to provide a patch, but that limitation really is a huge problem for 
embedding projects like this one (which, BTW, are needed for better 
acceptance of Java by the end users of the applications).

I tried three things: (a) Keep the JavaVM* pointer and do not load a 
second time, (b) Always LoadLibrary but never unload, (c) Always 
LoadLibrary and FreeLibrary even in the same single method. In fact, all 
three ways of handling procude the same problem: Everything works well 
(since Windows kindly maps the DLL to the same memory region ever as it 
seems), but AttachCurrentThread crashs down.
> Did you try using explicit linking (use LoadLibrary, GetProcAddress, 
> etc) for jvm.dll so it won't automatically get unloaded when your DLL 
> does?
Yes, see above.
> Are you able to catch the crash in a debugger and provide a symbolic 
> stack trace? I have a feeling it will reflect the limitation mentioned 
> above, so it may not lead to a solution, but it might be educational.
Unfortunately I do not know how. I have no full C++ development 
environment but just work with the free Microsoft Compiler plus a text 
editor.
> Steve
>
> P.S. Be careful embedding Java (or any single instance runtime) in a 
> shell extension: 
> http://blogs.msdn.com/junfeng/archive/2005/11/18/494572.aspx.  Many of 
> the limitations mentioned here for CLR will also apply to Java.
Yes I thought about that right from the start. Maybe I will change my 
architecture to not use JNI in the Shell Extension, but to instead call 
an out-of-process COM server implementation (a server EXE) that drives 
JNI instead, but I did not yet do it because I feared for the 
performance penalties of crossing process borders.

It is really a pity that JNI does not allow to create more than one VM 
actually, and I think a lot of JNI users would be really happy when 
fixing that. Maybe one day some kind programmer provides that. :-)

Thanks a lot
Markus
>
> Markus KARG wrote:
>
>> Hello Hotspot Community,
>>
>> I experienced a problem when using JNI and since nobody else was able 
>> to help me since months, and since it looks like a bug in the 
>> jvm.dll, you are my last chance. :-)
>>
>> In fact I am an experienced JNI user so my question is not about JNI 
>> itself but about a very complex case that makes jvm.dll crash down. 
>> So I want to discuss with you how we can solve it -- either by 
>> working around it in my code, or by adding a fix to the Hotspot VM 
>> (which seems to be the cause of the problems).
>>
>> I am writing a DLL in Windows XP that itself is a plugin to the 
>> desktop, a.k.a "Shell Extension". The DLL itself runs really stable 
>> (in fact I have drilled down so far that it actually does nothing 
>> anymore now, so I am pretty sure there is no bug in it since there is 
>> no more "real" code in it besides creating the Java VM). explorer.exe 
>> (i. e. the desktop process of Windows) loads the DLL, executes my 
>> code, and unloads the DLL then. So far, so good, works pretty well.
>>
>> But the same Windows process then loads my DLL once more, and 
>> executes it again (just as it did before). My DLL, you can imagine, 
>> is using JNI to call some Java code. Certainly I was clever enough 
>> not to create a VM twice, since I certainly know that both is 
>> impossible, either creating two VMs in the same process, or to try to 
>> create a VM after the previous VM was deleted (which I think is a 
>> bug, but anyways, that is not the point here).
>>
>> So I am checking first wheter there is a VM already using 
>> JNI_GetCreatedJavaVMs which returns the number of 1 and a pointer to 
>> the JavaVM. Great. That works pretty well. But if I now try to call 
>> AttachCurrentThread to get a pointer to the Env, then the desktop 
>> totally crashs down, telling me that I tried to execute code that 
>> actually is data (I switched off Data Execution Prevention then, but 
>> now it crashs down without ANY further note, so it is not a real 
>> help). So why did that happen?
>>
>> I looked at the source code of the JVM and it seems as if it uses 
>> global variables very heavily in the JNI source files. I could 
>> imagine that in fact one of those pointers now (after explorer 
>> unloaded and reloaded my DLL in the same process) point to a memory 
>> page that is marked as "data" but not as "code", so when using the 
>> function pointer, windows crashs down (since the memory pointed to is 
>> presumably no more part of the process's memory map).
>>
>> Please help me. I do not have any idea how to fix that. As a 
>> workaround I told Windows not to ever unload my DLL (what is 
>> working), but that certainly is just a bad hack. The real solution 
>> must be to convince jvm.dll to attach the thread without crashing down.
>>
>> If needed, I can provide an "at most simple" project that proofs the 
>> behaviour on any Windows machine (without seriously damaging it).
>>
>> Thanks!
>> Markus
>>
>


-- 
http://www.xing.com/go/invita/58469

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3505 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070809/8fdd9010/attachment.bin