You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dale Ogilvie <Da...@trimble.com> on 2013/04/04 05:27:32 UTC

Buggy java native call kills tomcat

Hi all,

 

Saw this recently... Some java native code included in our tomcat
deployment contained an error, which caused a JVM segfault when a
webapp called the routine.

 

I was startled by the fact that this native code error brought down the
entire tomcat instance (all 15+ web apps) due to a fault in a native
library (installed in tomcat/lib) called by one app.

 

This would have been very scary if this happened in PROD instead of
dev/test.

 

My question: can we protect ourselves from total instance failure, i.e.
restrict the damage to the death of just the app calling the native
library? Is there a way to make the tomcat VM survive a badly written
native component?

 

Thanks

 

Dale


RE: Buggy java native call kills tomcat

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Dale Ogilvie [mailto:Dale_Ogilvie@trimble.com] 
> Subject: Buggy java native call kills tomcat

> My question: can we protect ourselves from total instance failure, i.e.
> restrict the damage to the death of just the app calling the native
> library? Is there a way to make the tomcat VM survive a badly written
> native component?

Simple answer: nope.  In a Windows or Linux environment, native code has full access to the entire address space of the process, and can therefore scribble over anything it feels like, corrupting the JVM.  In general, you should try to avoid native code called from Java like the plague; not doing so means you might as well write in C (or worse, C++).  If you must use native code, running it in a separate process and communicating with it via pipes or sockets is much safer, but then you have to deal with timeouts and other error recovery issues.  Another option is to run a webapp that uses native code in a separate Tomcat instance (using a different port), and forward requests to it from the primary Tomcat.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org