More info from Hotspot engineers.
Does webstart allow running your own native code in an applet? (Does
plugin while
So I am guessing that they have java interfaces using the jvm/JIT
- then gluegen -- how does gluegen work here? Is it precompiled
or does it do a translation at run time?
- which talks to OpenCL C binaries
- there appear to be a set running on the host or main CPU,
including interfacing to the underlying device drivers, such as
the amd and nvidia drivers mentioned
- which then can also start OpenCL C binaries that run on
auxiliary processors like GPUs
So to answer Michael's question from a VM perspective:
It appears that the amd and nvidia native drivers that I would guess
they link to in their
host code register for the system signals listed below, but don't
support signal chaining,
i.e. they are overwriting the jvm's signal handlers.
So - the technical solution for that, assuming we can't change the amd
and nvidia drivers,
is to interpose our libjsig.so before their libraries are loaded. This
lets our vm chain
their signal handlers, so that the VM only handles signals that apply
to the vm and then
calls their signal handlers.
I am guessing they can't link libjsig with their application or he
would have done so - but
it is worth first asking why he can't.
If it is the case that he can not, then he needs to setenv LD_PRELOAD
libjvm.so-directory/libjsig.so
before starting up java.
Is there a way to do that with WebStart? Is there a way to specify to
do that?
No - there is no ability to set any env variables before launching
java. If jnlp file itself is signed and trusted, you could set system
propertys before launching java, but not environmental variables.
-
Paul
A partial answer: one of the Hotspot engineers says
I think the short answer is that chaining requires LD_PRELOAD to
override the signal entry points. Otherwise we [Hotspot] wouldn't see
the calls that change the signal handlers. If the Java command itself
linked against jsig that would work too I think. I believe that's the
only way to solve the problem he is seeing in an automatic fashion.
Depending on how the driver library gets loaded they might be able to
build their own signal handler trampolines to work around it and
correct the signal handlers after it gets loaded.
Regards,
Paul
On 5/8/10 7:31 AM, Michael Bien wrote:
Hello everyone,
i am one of the maintainers of JOGL and wrote JOCL
(http://jogamp.org/) and we are currently facing some signal handling
issues caused by the nvidia and amd drivers.
(I got the hint to post to this list since there is no better alias
for this kind of topics)
e.g. the nvidia OpenCL driver uses at least the following handlers:
Warning: SIGSEGV handler expected:libjvm.so+0x5d8cf0
found:libnvidia-compiler.so+0x1865e0
Warning: SIGILL handler expected:libjvm.so+0x5d8cf0
found:libnvidia-compiler.so+0x1865e0
Warning: SIGFPE handler expected:libjvm.so+0x5d8cf0
found:libnvidia-compiler.so+0x1865e0
Warning: SIGBUS handler expected:libjvm.so+0x5d8cf0
found:libnvidia-compiler.so+0x1865e0
Warning: SIGXFSZ handler expected:libjvm.so+0x5d8cf0
found:libnvidia-compiler.so+0x1865e0
(-Xcheck:jni)
which basically makes the jvm unusable on Linux and leads to
segmentation faults (in the driver, I suppose the driver catches jvm
signals).
LD_PRELOAD
(http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/signals.html#gbzbl)
works perfectly but it is not allowed for webstart + applets...
do you have any advice how we could workaround this issue? The
perfect solution would be a -XX:enableSignalChaining flag which we
could set via jnlp. Since the webstart JVM is out of process anyway
(since u10 or so) this would probably work.
Why isn't signal chaining enabled by default on linux and solaris? It
looks like a good self-defence mechanism for me :)
best regards,
Michael Bien
---
http://michael-bien.com
