(In reply to comment #1)
> Created an attachment (id=24870) [details]
> hs_err_pid5364.log
Microsoft Windows XP Professional 5.01.2600 Service Pack 3 US English
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing)
I never see an hs_err_pid<number>.log file in $CATALINA_HOME\bin, but otherwise the behavior when running Tomcat 6.0.14 from catalina.bat is the same.
However when I run Tomcat as a service, I do not see this error. I set the logging to debug, and checked $CATALINA\logs and the event viewer. The service starts and stops without an error.

I get the same result as Mark Eggers, i.e. the Exception in the log but no hotspot error file.
Microsoft Windows XP Professional
Version 5.1.2600 Service Pack 3 Build 2600
German
JRE 1.6.0_18
Interestingly in my case there is a localized message:
24.01.2010 10:38:45 org.apache.tomcat.util.net.AprEndpoint$Acceptor run
SCHWERWIEGEND: Socket accept failed
org.apache.tomcat.jni.Error: Ein Blockierungsvorgang wurde durch einen Aufruf von WSACancelBlockingCall unterbrochen.
at org.apache.tomcat.jni.Socket.accept(Native Method)
at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:1156)
at java.lang.Thread.run(Unknown Source)
So maybe it has to do with the Russian localization?
I also tried once with the security manager, same behavior.

1. When the crash happens, no event is recorded in the Event Viewer. I think that the crash is intercepted by JVM (that writes that crash report file) so the system does not know about it. The crash report file is written to the current working directory of java process. In my case it was %CATALINA_HOME%/bin, but it can be elsewhere. Though it might be, indeed, that 6.0.14 does not experience the crash. Thank you for the report.
2. Attachment 24903[details] - a batch file, that calls catalina start/stop in a cycle with some small delays.
Even if I cannot always reproduce the error with several tries, I can reproduce it with the batch.
3. The message, that is printed by org.apache.tomcat.jni.Error, in English will be
"A blocking operation was interrupted by a call to WSACancelBlockingCall"
It is the message for the WSAEINTR socket error code, and means that some function call was interrupted, see
http://support.microsoft.com/kb/819124
After playing a bit with the ".encoding" option of a FileHandler (in logging.properties) I was able to read it, but, indeed, TC-Native (or APR functions that it calls) does not respect system encoding. The message was processed with direct byte->char conversion, as if were in ISO-8859-1. By setting "1catalina.org.apache.juli.FileHandler.encoding = ISO-8859-1" and reading the log file with windows-1251 I was able to read it. It is wrong, but it is another issue.
So, it looks that this error message is expected. What is wrong is that it generates a crash.
4. I tested with TC 7(trunk), where I added diagnostic messages around the AprLifecycleListener.terminateAPR() method - see attachment 24904[details].
In the logs I see four variations of how the events happen:
a)
29.01.2010 6:26:16 org.apache.coyote.ajp.AjpAprProtocol destroy
INFO: Stopping Coyote AJP/1.3 on ajp-8009
29.01.2010 6:26:16 org.apache.catalina.core.AprLifecycleListener terminateAPR
INFO: Terminating APR
29.01.2010 6:26:16 org.apache.tomcat.util.net.AprEndpoint$Acceptor run
SEVERE: Socket accept failed
org.apache.tomcat.jni.Error: ???????? ???????????? ???????? ??????? WSACancelBlockingCall.
at org.apache.tomcat.jni.Socket.accept(Native Method)
at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:777)
at java.lang.Thread.run(Unknown Source)
29.01.2010 6:26:16 org.apache.catalina.core.AprLifecycleListener terminateAPR
INFO: Terminated APR
b)
29.01.2010 6:27:16 org.apache.coyote.ajp.AjpAprProtocol destroy
INFO: Stopping Coyote AJP/1.3 on ajp-8009
29.01.2010 6:27:17 org.apache.tomcat.util.net.AprEndpoint$Acceptor run
SEVERE: Socket accept failed
org.apache.tomcat.jni.Error: ???????? ???????????? ???????? ??????? WSACancelBlockingCall.
at org.apache.tomcat.jni.Socket.accept(Native Method)
at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:777)
at java.lang.Thread.run(Unknown Source)
29.01.2010 6:27:17 org.apache.catalina.core.AprLifecycleListener terminateAPR
INFO: Terminating APR
29.01.2010 6:27:17 org.apache.catalina.core.AprLifecycleListener terminateAPR
INFO: Terminated APR
c)
29.01.2010 6:34:19 org.apache.coyote.ajp.AjpAprProtocol destroy
INFO: Stopping Coyote AJP/1.3 on ajp-8009
29.01.2010 6:34:19 org.apache.catalina.core.AprLifecycleListener terminateAPR
INFO: Terminating APR
29.01.2010 6:34:19 org.apache.catalina.core.AprLifecycleListener terminateAPR
INFO: Terminated APR
d)
29.01.2010 6:40:45 org.apache.coyote.ajp.AjpAprProtocol destroy
INFO: Stopping Coyote AJP/1.3 on ajp-8009
29.01.2010 6:40:45 org.apache.catalina.core.AprLifecycleListener terminateAPR
INFO: Terminating APR
29.01.2010 6:40:45 org.apache.catalina.core.AprLifecycleListener terminateAPR
INFO: Terminated APR
29.01.2010 6:40:45 org.apache.tomcat.util.net.AprEndpoint$Acceptor run
SEVERE: Socket accept failed
org.apache.tomcat.jni.Error: ???????? ???????????? ???????? ??????? WSACancelBlockingCall.
at org.apache.tomcat.jni.Socket.accept(Native Method)
at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:777)
at java.lang.Thread.run(Unknown Source)
When c) happens, a crash report file is generated.
The AprLifecycleListener.terminateAPR() method calls o.a.t.jni.Library#terminate() that is implemented as a method in jnilib.c.
TCN_IMPLEMENT_CALL(void, Library, terminate)(TCN_STDARGS)
calls
apr_pool_destroy(p);
apr_terminate();
so if return from
TCN_IMPLEMENT_CALL(jlong, Socket, accept)(TCN_STDARGS, jlong sock)
of network.c happens after that call ends, as in d), it will face a destroyed pool and terminated APR. Thus it is no wonder that EXCEPTION_ACCESS_VIOLATION is reported.
5. So, the question is why
org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:1156)
was still running when AprLifecycleListener.terminateAPR() was already called.

I still wonder, what is causing this at the Java side:
(see 5. in Comment 8): what is closing those sockets and whether it is possible to wait for termination of those Acceptor threads before going on and calling Library.terminate()?
Due to asynchronous nature of this issue, there is still a time frame in r907567 between if(tcn_global_pool) check and apr_pool_destroy(p) call when apr termination can occur. Though that is probably negligible. It is better to go with r907567 than without.
The TCN_THROW_IF_ERR can still be called with terminated APR, but that is probably safe -- I think that apr_strerror() call (inside tcn_ThrowAPRException() that is called from TCN_THROW_IF_ERR macro) should still work even after APR is terminated.

This is ASF Bugzilla: the Apache Software Foundation bug system. In case
of problems with the functioning of ASF Bugzilla, please contact
bugzilla-admin@apache.org.
Please Note: this e-mail address is only for reporting problems
with ASF Bugzilla. Mail about any other subject will be silently
ignored.