On 2 October 2013 06:18, Mladen Turk <mt...@apache.org> wrote: > On 10/01/2013 07:32 PM, sebb wrote: >> >> >> If a Java application succeeds in crashing the JVM, then IMO the JVM >> has a bug. I believe that all native code should strive to behave the >> same way. >> > > This is conceptual difference.
Partly. > Most of those checks are done again inside Java. > However inside JVM the Java API hides its native methods and > ensures params are validated. > Our API is Servlet spec and our VM is Tomcat. AFAIK tcnative does not hide its native methods. If it did, I agree it should be possible to guarantee correct parameters, regardless of application code behaviour. > All the invalid data should be checked in java part which can be > invalid as part of normal operation. Our native code already checks > for some invalid data which can be invalid in such situations. > OTOH invalid data passed to native caused by bug is just that, a bug. > So fix the bug and you won't need the check. The problem is that bugs that reveal themselves as JVM crashes are much harder to debug. > We can add compile time '#if defined(MAINTAINER_MODE) ... #endif' checks > for easier debugging at development, Any crashes that occur in a released version of TC are likely to be fairly rare, otherwise they would be detected in testing. So the MAINTAINER_MODE is not likely to be much use after the initial shakedown period. Unless the debugging checks are expensive, why not leave them in? > but all the checks inside native method > can be equally well coded before the actual JNI call and since our API is > servlet > and no use code can pass beyond that. > Tomcat code that calls tcnative directly needs to validate its parameters; the more places that TC code has direct access to tcnative, the more likely that some checks will be overlooked. And more effort will be required to retro-fit any extra checks that are found necessary. Also AIUI tcnative code may be used separately from Tomcat. > > > Regards > -- > ^TM > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
