Bug 620996

Summary: upgrade to tomcat5-5.5.23-0jpp.9.el5_5 causes StackOverflowError
Product: Red Hat Enterprise Linux 5 Reporter: Bryan Maupin <bmaupin>
Component: tomcat5Assignee: David Knox <dknox>
Status: CLOSED ERRATA QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: urgent    
Version: 5.5.zCC: azelinka, bmaupin, jclere, jscotka, ofourdan, paul.deaudney, superber, syeghiay, tao
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
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-14 00:09:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 623254    
Attachments:
Description Flags
log snippet showing errors when shutting down and restarting Tomcat none

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