Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Message-ID: <5249B7FE.2060200@apache.org>
Date: Mon, 30 Sep 2013 19:42:22 +0200
From: Mladen Turk <mturk@apache.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: dev@tomcat.apache.org
Subject: Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45
 [tcnative-1.dll+0x7e23]
References: <5246199A.70000@christopherschultz.net>
 <5246AEB6.5050509@kippdata.de> <5246B613.6010504@apache.org>
 <52492924.1040205@apache.org> <52497DE2.4010007@apache.org>
 <524999BB.1010007@christopherschultz.net>
In-Reply-To: <524999BB.1010007@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.


Regards
-- 
^TM

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