Bug 620996 - upgrade to tomcat5-5.5.23-0jpp.9.el5_5 causes StackOverflowError
Summary: upgrade to tomcat5-5.5.23-0jpp.9.el5_5 causes StackOverflowError
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: tomcat5
Version: 5.5.z
Hardware: x86_64
OS: Linux
urgent
medium
Target Milestone: rc
: ---
Assignee: David Knox
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 623254
TreeView+ depends on / blocked
 
Reported: 2010-08-03 22:36 UTC by Bryan Maupin
Modified: 2018-10-27 13:21 UTC (History)
9 users (show)

Fixed In Version: tomcat5-5_5_23-0jpp_11_el5_5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-14 00:09:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
log snippet showing errors when shutting down and restarting Tomcat (555.14 KB, application/octet-stream)
2010-08-03 22:36 UTC, Bryan Maupin
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0138 0 normal SHIPPED_LIVE tomcat5 bug fix update 2011-01-12 19:26:40 UTC

Description Bryan Maupin 2010-08-03 22:36:18 UTC
Created attachment 436396 [details]
log snippet showing errors when shutting down and restarting Tomcat

We recently upgraded to tomcat5-5.5.23-0jpp.9.el5_5 from tomcat5-5.5.23-0jpp.7.el5_3.2.  When we restarted tomcat all of our web applications failed to load, instead giving us a java.lang.StackOverflowError for each application it tried to deploy:

Aug 3, 2010 12:33:21 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive [removed]
Aug 3, 2010 12:33:21 PM org.apache.catalina.startup.HostConfig deployWAR
SEVERE: Error deploying web application archive [removed]
java.lang.StackOverflowError
        at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:58)
        at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:392)
        at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:447)
        at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:544)
        at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:240)
        at java.lang.StringCoding.encode(StringCoding.java:272)
        at java.lang.String.getBytes(String.java:946)
        at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
        at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)
        at java.io.File.isDirectory(File.java:754)
        at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:360)
        at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:361)
(the last line repeated 1012 times)

The same thing seems to happen when we shutdown Tomcat.  For each app it tries to undeploy, it gives a stack overflow error:

Aug 3, 2010 12:31:33 PM org.apache.catalina.startup.HostConfig undeployApps
WARNING: Error while removing context [removed]
java.lang.StackOverflowError
        at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:58)
        at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:392)
        at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:447)
        at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:544)
        at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:240)
        at java.lang.StringCoding.encode(StringCoding.java:272)
        at java.lang.String.getBytes(String.java:946)
        at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
        at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)
        at java.io.File.isDirectory(File.java:754)
        at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:360)
        at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:361)
(the last line repeated 1012 times)

I'm guessing it's some kind of infinite loop that eventually causes Tomcat to run out of memory.  Once we downgraded to the old version of Tomcat, everything started working fine again.

We're using Sun Java 1.6 and RHEL 5.5:

$ cat /etc/*release
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
$ java -version
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)
$ rpm -qa java-1.6.0-sun
java-1.6.0-sun-1.6.0.21-1jpp.2.el5

I'm not sure if this a related issue or not, but it seemed to be similar:

https://jira.jboss.org/browse/JBPAPP-3753?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel#issue-tabs

Comment 7 albert 2010-08-06 09:07:37 UTC
Same here, with Sun Java 1.5

Comment 10 Paul De Audney 2010-08-30 08:15:37 UTC
I believe "RHSA-2010:0580 - Security Advisory" specifically (CVE-2009-2693, CVE-2009-2902) to be cause of this.

The patch tomcat5-5.5.23-CVE-2009-2693-2901-2902.patch appears to be source of the brokenness.

The patch applies to the tomcat5-server-lib-5.5.23-0jpp.9.el5_5 package.

This is the ExpandWar.delete(...) method after applying patch.

Bring on the loop.

/**
 * * Delete the specified directory, including all of its contents and
 * * subdirectories recursively.
 * *
 * * @param dir File object representing the directory to be deleted
 * * @param logFailure <code>true</code? if failure to delete the resource
 * * should be logged
 * */
public static boolean delete(File dir, boolean logFailure)
{
	boolean result;
	if (dir.isDirectory()) {
		result = delete(dir, logFailure); <-------- FIX ME RED HAT!
	} else {
		if(dir.exists()) {
			result = dir.delete();
		} else {
			result = true;
		}
	}
	if (logFailure && !result) {
		log.error(sm.getString(
		"expandWar.deleteFailed", dir.getAbsolutePath()));
	}
	return result;
}


Can we get an ETA on the fix for this?

Comment 18 errata-xmlrpc 2011-01-14 00:09:18 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0138.html


Note You need to log in before you can comment on or make changes to this bug.