tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]
Date Thu, 03 Oct 2013 12:51:07 GMT
Sebb,

On 10/3/13 8:06 AM, sebb wrote:
> The problem is that bugs that reveal themselves as JVM crashes are
> much harder to debug.

+1

This is exactly the point I was arguing. When we get a JVM crash report,
the stack dump could be completely different depending upon which
architecture, kernel, compiler, optimization flags, etc. that were used
when compiling and/or running the library. Converting SIGSEGV into an
exception gives us a lot of freedom to publish tons of useful
information when reporting errors to the user.

I'd rather get a report from a user that says something like "here is my
stack trace and error message, complete with name of variable that was
NULL and line of source code" rather than "here's my JVM crash report,
sorry I didn't get a core file, I'm having trouble reproducing the
error" (which is essentially what all currently-open JVM-crash error
reports look like in BZ for tcnative).

>> 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?

Obviously given my previous comments, I agree with this. If the
MAINTAINER had an exhaustive set of unit tests, there would be no error
reports, right? ;) I argue that MAINTAINER_MODE is exactly the opposite
of what you want: you want real users to have this information precisely
because they are *not* programmers (at least not C programmers).

-chris


Mime
View raw message