Rainer,
On 10/3/13 7:01 PM, Rainer Jung wrote:
On 04.10.2013 00:37, Christopher Schultz wrote:
Rainer,
On 10/3/13 5:40 PM, Rainer Jung wrote:
On 03.10.2013 21:52, Mark Thomas wrote:
On 03/10/2013 17:34, Christopher Schultz wrote:
On 10/3/13 11:42 AM, Mark Thomas wrote:
I was thinking
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.
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,
On 03/10/2013 13:51, Christopher Schultz wrote:
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
Mark,
On 10/3/13 9:18 AM, Mark Thomas wrote:
On 03/10/2013 13:51, Christopher Schultz wrote:
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
On 03/10/2013 16:12, Christopher Schultz wrote:
On 10/3/13 9:18 AM, Mark Thomas wrote:
Having been responsible for introducing and fixing a number of
these issues I disagree. It is usually fairly easy to tell what
the problem is from the crash report (double close on a socket,
invalid socket
Mark,
On 10/3/13 11:42 AM, Mark Thomas wrote:
On 03/10/2013 16:12, Christopher Schultz wrote:
On 10/3/13 9:18 AM, Mark Thomas wrote:
Having been responsible for introducing and fixing a number of
these issues I disagree. It is usually fairly easy to tell what
the problem is from the crash
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2013 17:34, Christopher Schultz wrote:
On 10/3/13 11:42 AM, Mark Thomas wrote:
On the other hand, a JVM crash is a very strong motivation to fix
an issue.
For *you*, or for the user?
For me. I haven't looked at the historical bugs.
On 03.10.2013 21:52, Mark Thomas wrote:
On 03/10/2013 17:34, Christopher Schultz wrote:
On 10/3/13 11:42 AM, Mark Thomas wrote:
I was thinking maybe an APR function that gave a textual error message
for a given error code. Currently, the APR Java code reports just the
error number. It would
Mark,
On 10/3/13 3:52 PM, Mark Thomas wrote:
On 03/10/2013 17:34, Christopher Schultz wrote:
On 10/3/13 11:42 AM, Mark Thomas wrote:
On the other hand, a JVM crash is a very strong motivation to fix
an issue.
For *you*, or for the user?
For me. I haven't looked at the historical bugs.
Mark,
On 10/3/13 6:29 PM, Christopher Schultz wrote:
Okay, that's something I can do: a JNI wrapper around apr_strerror
should be trivial.
Already exists:
public static native String org.apache.tomcat.jni.Error.strerror(int
statcode);
-chris
signature.asc
Description: OpenPGP digital
Rainer,
On 10/3/13 5:40 PM, Rainer Jung wrote:
On 03.10.2013 21:52, Mark Thomas wrote:
On 03/10/2013 17:34, Christopher Schultz wrote:
On 10/3/13 11:42 AM, Mark Thomas wrote:
I was thinking maybe an APR function that gave a textual error message
for a given error code. Currently, the APR
On 04.10.2013 00:37, Christopher Schultz wrote:
Rainer,
On 10/3/13 5:40 PM, Rainer Jung wrote:
On 03.10.2013 21:52, Mark Thomas wrote:
On 03/10/2013 17:34, Christopher Schultz wrote:
On 10/3/13 11:42 AM, Mark Thomas wrote:
I was thinking maybe an APR function that gave a textual error
On 01.10.2013 06:53, Mladen Turk wrote:
On 09/30/2013 08:50 PM, Christopher Schultz wrote:
Mladen,
Unless there is significant objection,
Yes there is.
The transition from Java to JNI costs 10 times then
then a simple 'if (socket == OL)' in java
I'd like to add such NULL checks
to
Mladen and Rainer,
On 10/1/13 2:59 AM, Rainer Jung wrote:
On 01.10.2013 06:53, Mladen Turk wrote:
On 09/30/2013 08:50 PM, Christopher Schultz wrote:
Mladen,
Unless there is significant objection,
Yes there is.
The transition from Java to JNI costs 10 times then
then a simple 'if (socket
Mladen,
On 10/1/13 10:39 AM, Mladen Turk wrote:
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
On 1 October 2013 15:47, Christopher Schultz
ch...@christopherschultz.net wrote:
Mladen,
On 10/1/13 10:39 AM, Mladen Turk wrote:
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
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.
Most of those checks are done again inside Java.
However inside JVM the
On 28/09/2013 11:57, Mladen Turk wrote:
On 09/28/2013 12:25 PM, Rainer Jung wrote:
I can't seem to reproduce the problem using an APR connector on Linux:
reports seems to indicate that trivially accessing Tomcat via an HTTP
APR connector will cause a crash, and I was able to run the following
On 30/09/2013 08:32, Mark Thomas wrote:
On 28/09/2013 11:57, Mladen Turk wrote:
On 09/28/2013 12:25 PM, Rainer Jung wrote:
I can't seem to reproduce the problem using an APR connector on Linux:
reports seems to indicate that trivially accessing Tomcat via an HTTP
APR connector will cause a
On 09/30/2013 03:34 PM, Mark Thomas wrote:
I'd like to try and make the changes as a series of small, incremental,
easy to review changes. I'm not sure how feasible that will be. I hope
to have this fixed in the next day or so.
Cool.
Not sure if socket wrapper is created for each native
Mark,
On 9/30/13 9:34 AM, Mark Thomas wrote:
On 30/09/2013 08:32, Mark Thomas wrote:
On 28/09/2013 11:57, Mladen Turk wrote:
On 09/28/2013 12:25 PM, Rainer Jung wrote:
I can't seem to reproduce the problem using an APR connector on Linux:
reports seems to indicate that trivially accessing
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,
Mladen,
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,
On 09/30/2013 08:50 PM, Christopher Schultz wrote:
Mladen,
Unless there is significant objection,
Yes there is.
The transition from Java to JNI costs 10 times then
then a simple 'if (socket == OL)' in java
I'd like to add such NULL checks
to limit JVM crashes in cases where the Java code
Hi Chris,
On 28.09.2013 01:49, Christopher Schultz wrote:
All,
I know Mark and Rainer are working on trying to avoid corruption of what
looks like pollset counts or whatever, but I wanted to know if anyone
can help me decode the cause of the null-dereference that's occurring.
Obviously
On 09/28/2013 12:25 PM, Rainer Jung wrote:
I can't seem to reproduce the problem using an APR connector on Linux:
reports seems to indicate that trivially accessing Tomcat via an HTTP
APR connector will cause a crash, and I was able to run the following
command without bringing down my
All,
I know Mark and Rainer are working on trying to avoid corruption of what
looks like pollset counts or whatever, but I wanted to know if anyone
can help me decode the cause of the null-dereference that's occurring.
Obviously bandaging the symptom is not the best solution, but keeping
the JVM
28 matches
Mail list logo
