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:
>>
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 t
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,
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
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 hi
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 w
-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 bu
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 fro
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,
>> invali
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. Whe
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
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, c
On 2 October 2013 06:18, Mladen Turk 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.
> Mo
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 Java
On 1 October 2013 15:47, Christopher Schultz
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 still be
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: instea
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 :)
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
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
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 is
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
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,
j
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 tr
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 socke
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 connect
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 th
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 instance
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.
>
> Obvio
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
29 matches
Mail list logo
