signal chaining and self defence

Paul Hohensee paul.hohensee at
Tue May 11 18:53:40 UTC 2010

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 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 
 >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.

> 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 
>> ( 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 
>> Warning: SIGILL handler 
>> Warning: SIGFPE handler 
>> Warning: SIGBUS handler 
>> Warning: SIGXFSZ handler 
>> (-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).
>> ( 
>> 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
>> ---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the core-libs-dev mailing list