tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <>
Subject Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]
Date Tue, 01 Oct 2013 14:39:17 GMT
On 10/01/2013 04:15 PM, Christopher Schultz wrote:
> Mladen and Rainer,
>>> -1. You are just hiding the reason for crash.
> I disagree: the reason for the crash can still be reported. It just
> won't be reported with a JVM crash: instead, there will be an exception.

I disagree on your disagreement :)

This can be easily done in Java with much cheaper computing cost.
If you suspect the data fed to native call can be faulty, well check it
and throw java exception instead calling native, and distinguishing between valid
and error return values from native and then still have a code which will
pass/throw. I know it requires a different thinking then average library,
but it's not an average library. It's wrapper for APR and APR expects you
provide valid data.

Even checking in native won't solve crashes. You can fed a long (pointer)
which is in zombie state (closed but not null) and you'll have a memory
location which will pass null check but can still crash or even corrupt
other memory location if it was reused by another alloc.
Much harder to track down.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message