On 17.01.2012 11:16, Mark Thomas wrote:
The proposed Apache Tomcat 7.0.25 release is now available for voting.
It can be obtained from:
http://people.apache.org/~markt/dev/tomcat-7/v7.0.25/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-082/
The svn tag is:
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_25/
The proposed 7.0.25 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 7.0.25 Stable
I dropped both alpha and beta as if it is not stable, I'll re-roll the
release.
+1, some unit test failures which seem to be timing issues, but one
crash in APR, this time another test and during
AprLifecycleListener.terminateAPR() -> apr_pool_terminate() ->
apr_allocator_destroy(). But those sporadic crashes observe are not
regressions.
Details:
- MD5 OK
- signatures OK
- key in KEYS file
- gz and zip for src and bin consistent
- src consistent with svn tag, except for the following minor points
(no regression)
- line ends of modules/jdbc-pool/resources/MANIFEST.MF differ
between svn and gz although eol-style is set correctly.
- the files we copy before building, e.g.
catalina.properties and jdbc-pool.xml are of course
not in svn for the cp target location, but they are
in the src bundles.
- builds fine
- build result looks consistent with binaries
- no checkstyle complaints
- no Javadoc errors
- Unit tests some spurious failures and one APR crash
(probably not a regression):
- TestWebappClassLoaderMemoryLeak (NIO): Timer thread still running
- TestAsyncContextImpl (NIO): one failure in line 172,
because response time was 975 ms, which is not >= 1000
- TestSwallowAbortedUploads (APR): crash during tearDown().
Details see at end of this mail.
- JMX MBean-Comparison only expected differences:
- Attribute "-requestBytesSent" for RequestProcessor related
to thread http-bio-8080-exec-1 shows "0" instead of "131072".
This is likely a consequence of the JMXProxy now first formatting
the complete result via the MBeanDumper and then writing back
everything, so at the time of formatting nothing was written yet,
so byte count "0". I checked with a request streaming data and
when I dump the MBeans in parallel, I can see the correct
requestBytesSent in the MBean for that streaming request.
- New attribute "localPort" in Connector, ProtocolHandler
and ThreadPool MBeans
- New attribute "nameIndex" in ProtocolHandler MBean
- slightly different sorting for "rejectedSessions"
- two new loggers (o.a.c.mbeans and o.a.c.mbeans.MBeanDumper)
Build and tests were done using Java 1.6.0_30, OS was Solaris 10 Sparc,
tcnative was 1.1.22 based on APR 1.4.5 and OpenSSL 1.0.0f.
Details about APR crash:
Crash in
Testcase: testAbortedUploadUnlimitedSwallow took 0.004 sec
during tearDown in the library allocator destruction:
fe024970 apr_allocator_destroy (293930, fc041180, 140, 0, 0, 0) + 10
fe025690 apr_pool_terminate (31928, fe37dcd0, 40800, 0, 0, 34000) + 44
fc00d700 * org/apache/tomcat/jni/Library.terminate()V+-19432
fc00d6ac * org/apache/tomcat/jni/Library.terminate()V+0
...
fc005940 *
org/apache/catalina/core/AprLifecycleListener.terminateAPR()V+23 (line 295)
fc005ab0 *
org/apache/catalina/core/AprLifecycleListener.lifecycleEvent(Lorg/apache/catalina/LifecycleEvent;)V+151
(line 243)
fc005fd0 *
org/apache/catalina/util/LifecycleSupport.fireLifecycleEvent(Ljava/lang/String;Ljava/lang/Object;)V+37
(line 235)
fc005ab0 *
org/apache/catalina/util/LifecycleBase.fireLifecycleEvent(Ljava/lang/String;Ljava/lang/Object;)V+6
(line 180)
fc005ab0 *
org/apache/catalina/util/LifecycleBase.setStateInternal(Lorg/apache/catalina/LifecycleState;Ljava/lang/Object;Z)V+140
(line 753)
fc005ab0 * org/apache/catalina/util/LifecycleBase.destroy()V+275 (line
585)
fc005fd0 * org/apache/catalina/startup/Tomcat.destroy()V+9 (line 709)
fc005ab0 * org/apache/catalina/startup/TomcatBaseTest.tearDown()V+57
(line 321)
Debugger says:
apr_allocator_destroy (allocator=0x293930) at memory/unix/apr_pools.c:143
Line 143 is the first line in the following while loop:
APR_DECLARE(void) apr_allocator_destroy(apr_allocator_t *allocator)
{
apr_uint32_t index;
apr_memnode_t *node, **ref;
for (index = 0; index < MAX_INDEX; index++) {
ref = &allocator->free[index];
while ((node = *ref) != NULL) {
*ref = node->next;
#if APR_ALLOCATOR_USES_MMAP
munmap(node, (node->index+1) << BOUNDARY_INDEX);
#else
free(node);
#endif
}
}
...
It crashes there, because it tries to dereference the invalid
address 0x4f28 at allocator->free[1]:
(gdb) print *allocator
$1 = {max_index = 16, max_free_index = 0, current_free_index = 0, mutex
= 0x0, owner = 0x286420, free = {0x0, 0x4f28, 0x0 <repeats 14 times>,
0xaf1998, 0x0, 0x0, 0x0}}
Some more data:
(gdb) print *allocator->owner
$2 = {parent = 0x74726f6c, child = 0x2f627569, sibling = 0x6c642f73, ref
= 0x6f6c6172, cleanups = 0x69732d73, free_cleanups = 0x70617263,
allocator = 0x2f62696e,
subprocesses = 0x2f6a6176, abort_fn = 0x61006372, user_data =
0x74692e73, tag = 0x637274 "", active = 0x312e7300, self = 0x5f5f6765,
self_first_avail = 0x745f6578 <Address 0x745f6578 out of bounds>,
pre_cleanups = 0x69745f66}
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
