tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]
Date Mon, 30 Sep 2013 18:50:41 GMT

On 9/30/13 1:42 PM, Mladen Turk wrote:
> On 09/30/2013 05:33 PM, Christopher Schultz wrote:
>> I may need a little more guidance, since adding NULL-checks for
>> everything is a little silly. Here is the function declaration in
>> tcnative:
>> TCN_IMPLEMENT_CALL(jint, Poll, poll)(TCN_STDARGS, jlong pollset,
>>                                       jlong timeout, jlongArray set,
>>                                       jboolean remove)
>> Presumably, the pollset itself is non-null, but could all of the items
>> in the pollset be null?
> APR does not check for parameter validity. Neither does TC native
> in most cases (checks are actually leftovers from initial debugging).
> It's up to java code to ensure params are valid, and thread safe if needed.
> I don't think there is nothing wrong with the native code. Using it is
> where the majority of problems happen. Neither thread safety or param
> checking should be part of native code. It's a thin low level wrapper.
> Everything else should be done in java.

While I agree that the Java code should be responsible for providing
good data to tcnative, the threat of a JVM crash should be enough of an
incentive to do simple things like NULL-checking.

r1518225 (granted, my commit) recently added NULL-checking for sockets
which will hopefully reduce crashes when sockets are incorrectly reused
under a number of conditions. I feel like the overhead is now
(NULL-checks are super cheap) and the reward is high (fewer JVM crashes).

Unless there is significant objection, I'd like to add such NULL checks
to limit JVM crashes in cases where the Java code isn't absolutely
perfect (with sincere apologies to all who manage the socket-management
code in Tomcat).


View raw message