FULL PRODUCT VERSION :
java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b06)
Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode, sharing)

FULL OS VERSION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Well don't know what this bug is actually about, only thing I can provide is hot spot error log and how to reproduce this.
We encountered this when working with JBoss's JMS implementation. From time to time a either JBoss's JVM crashed or JVM of client connecting to JBoss crashed. The error log was always the same with native frames:

C [ntdll.dll+0x18fea]
C [ntdll.dll+0x104b]

and java frames ending with:
j java.net.SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I+0

Altough we encountered it with JBoss, we believe that this is more general JVM problem.

I was able to create a simple program (below) which causes JBoss's JVM to crash every time, altough the time needed before the crash varies (from 1s to 10s). See below... I think I don't have to tell you how this threatens security of our servers ;). I will post the bug also on JBoss's bug database just in case that this bug is somehow their responsibility...

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Download fresh copy of stable version of JBoss (tested with 3.2.7, 4.2.0.GA - works for both) and jdk mentioned above.

2. run jboss by: %JBOSS_HOME%/bin/run.bat -c all

3. compile and run simple code from the "Source code for an executable test case" part of this bug report (you'll have to put this jar on classpath: "%JBOSS_HOME%/client/jbossall-client.jar"):

4. In short time JBoss's JVM crashes.... the time varies, but the crash is always there. We have encountered times from 1s to 10s.


EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: If there is something wrong with a socket when closing a connection we would expect some "normal" exception.
Actual: A client code causes JVM crash of JBoss.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
(see attachment hs_err.log)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.Properties;

import javax.jms.QueueConnection;
import javax.jms.QueueConnectionFactory;
import javax.naming.Context;
import javax.naming.InitialContext;

public class JBossCrash
{

    public static QueueConnection createNewConnection() throws Throwable {
        Properties F_env = new Properties();
        F_env.setProperty(Context.INITIAL_CONTEXT_FACTORY,
                "org.jnp.interfaces.NamingContextFactory");
        F_env.setProperty(Context.PROVIDER_URL, "localhost:1099");
        F_env.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming");

        InitialContext F_iniCtx = new InitialContext(F_env);
        QueueConnectionFactory F_connectionFactory = (QueueConnectionFactory)F_iniCtx
                .lookup("ConnectionFactory");
        QueueConnection F_connection = F_connectionFactory.createQueueConnection();
        
        return F_connection;
    }
    
    public static void main(String[] args)
        throws Throwable
    {
        System.out.println("Connection established, now quickly start, stop and close connections");
        // periodically create, start, stop and close connection to JBoss
        while (true)
        {
            System.out.println("cycle!");
            QueueConnection F_connection = createNewConnection();
            F_connection.start();
            F_connection.stop();
            F_connection.close();
        }

    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
No workaround for this. Just a recommendation for JMS clients to use only one JMS connection for every JMS communication. And possibly close this connection at the end of the application... This helped us to reduce the problem, but not eliminate it entirely...