Bug 620996 - upgrade to tomcat5-5.5.23-0jpp.9.el5_5 causes StackOverflowError
upgrade to tomcat5-5.5.23-0jpp.9.el5_5 causes StackOverflowError
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: tomcat5 (Show other bugs)
5.5.z
x86_64 Linux
urgent Severity medium
: rc
: ---
Assigned To: David Knox
qe-baseos-daemons
: ZStream
Depends On:
Blocks: 623254
  Show dependency treegraph
 
Reported: 2010-08-03 18:36 EDT by Bryan Maupin
Modified: 2015-11-01 19:15 EST (History)
9 users (show)

See Also:
Fixed In Version: tomcat5-5_5_23-0jpp_11_el5_5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-13 19:09:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0138 normal SHIPPED_LIVE tomcat5 bug fix update 2011-01-12 14:26:40 EST

  None (edit)
Description Bryan Maupin 2010-08-03 18:36:18 EDT
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 05:07:37 EDT
Same here, with Sun Java 1.5
Comment 10 Paul De Audney 2010-08-30 04:15:37 EDT
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-13 19:09:18 EST
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.