signal chaining and self defence

Paul Hohensee paul.hohensee at Sun.COM
Tue May 11 00:00:52 UTC 2010

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



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