[jboss-jira] [JBoss JIRA] Commented: (JBWEB-125) Crash ending an event driven HTTP connection

[Mladen Turk (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBWEB-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12436578#action_12436578 ] 

Mladen Turk commented on JBWEB-125:
-----------------------------------

Exception thrown is caused by:

>>> network.c : timeoutSet
    if (!sock) {
        tcn_ThrowAPRException(e, APR_ENOTSOCK);
        return APR_ENOTSOCK;
    }
<<<

However, crash and exception are not caused by the same socket.
I presume there is a race condition that closes the socket, setting it to zero afterwards
and timeoutSet is called at the same momemnt  by some other thread.
If timeoutSet happens while socket is beeing closed and its
long pointer wasn't set to zero yet, it will reference the zombie memory location.

This is probably related to JBAS-124 as well.

The point is that socket != 0 should be checked before calling
native method. Native is thin layer, and doesn't care much
about validity of provided params. It's up to the agregator to take
care of data validity and access synchronisation.


> Crash ending an event driven HTTP connection
> --------------------------------------------
>
>                 Key: JBWEB-125
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-125
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-2.1.1.GA
>            Reporter: Remy Maucherat
>            Assignee: Mladen Turk
>         Attachments: hs_err_pid5850.log
>
>
> I experienced a very rare crash when using events (bayeux stock ticker on localhost + F5), when setting back the socket timeout at the end of the processing. The odd part is that it seems to be caught with an exception (very good) but causes a JVM crash anyway.
> Oct 31, 2008 5:31:47 PM org.apache.coyote.http11.Http11AprProcessor event
> SEVERE: Error processing request
> org.apache.tomcat.jni.Error: Socket operation on non-socket
> 	at org.apache.tomcat.jni.Socket.timeoutSet(Native Method)
> 	at org.apache.coyote.http11.Http11AprProcessor.action(Http11AprProcessor.java:1262)
> 	at org.apache.coyote.Response.action(Response.java:184)
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:272)
> 	at org.apache.coyote.http11.Http11AprProcessor.event(Http11AprProcessor.java:786)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.event(Http11AprProtocol.java:544)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1988)
> 	at java.lang.Thread.run(Thread.java:636)
> #
> # An unexpected error has been detected by Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00b43521, pid=5850, tid=101182352
> #
> # Java VM: OpenJDK Server VM (1.6.0-b09 mixed mode linux-x86)
> # Problematic frame:
> # C  [libtcnative-1.so.0.1.15+0xf521]  Java_org_apache_tomcat_jni_Socket_timeoutSet+0x61
> #
> # An error report file with more information is saved as:
> # /home/remm/Work/jbossweb/jbossweb-2.1.x/output/build/hs_err_pid5850.log
> [thread 97975184 also had an error]
> #
> # If you would like to submit a bug report, please visit:
> #   http://icedtea.classpath.org/bugzilla
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> Assigning to Mladen since the error hints the crash can be avoided (as it seems detected already).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira