Bug 120844 - Attempting to access the admin webapp causes tomcat to crash
Attempting to access the admin webapp causes tomcat to crash
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: tomcat (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gary Benson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-14 10:12 EDT by Gary Benson
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 4.1.27-12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-16 11:32:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gary Benson 2004-04-14 10:12:41 EDT
Description of problem:
Attempting to access the admin webapp causes tomcat to crash.  This
has been observed using both the HTTP/1.1 and AJP/1.3 connectors.

Version-Release number of selected component (if applicable):
tomcat-4.1.27-11

How reproducible:
Always.

Steps to Reproduce:
1. Start your tomcat server.
2. Point your browser at http://h:p/admin/
3. Watch it die. Horribly.
  
Actual results:
The admin webapp's login page appears.

Expected results:
Tomcat crashes.
Comment 1 Oliver Falk 2004-04-14 10:22:19 EDT
Even if I run it not over the Coyote port (default 8080), Tomcat 
crashes... :-/
Comment 2 Gary Benson 2004-04-14 11:37:52 EDT
Got this from a coredump:

#0  0x0000003d1052edaf in raise () from /lib64/tls/libc.so.6
#1  0x0000003d1053084e in abort () from /lib64/tls/libc.so.6
#2  0x0000003e1a25f961 in _Jv_Throw (value=0x25abc58) at
../../../libjava/exception.cc:113
#3  0x0000003e1a25273f in _Jv_catch_segv (_p=0x447fe680) at
../../../libjava/prims.cc:148
#4  <signal handler called>
#5  0x0000003788241242 in org::w3c::dom::NodeList::class$ () from
/usr/lib64/lib-javax-xml-parsers-2.2.1.so
#6  0x00000037897a64f6 in
org::apache::jasper::xmlparser::ParserUtils::convert(org::apache::jasper::xmlparser::TreeNode*,
org::w3c::dom::Node*) ()
   from /usr/lib64/lib-org-apache-jasper-4.1.27.so
#7  0x00000037897a662c in
org::apache::jasper::xmlparser::ParserUtils::parseXMLDocument(java::lang::String*,
java::io::InputStream*) ()
   from /usr/lib64/lib-org-apache-jasper-4.1.27.so
#8  0x0000003789790bd7 in
org::apache::jasper::compiler::TldLocationsCache::processWebDotXml()
() from /usr/lib64/lib-org-apache-jasper-4.1.27.so
#9  0x0000003789790dd9 in
org::apache::jasper::compiler::TldLocationsCache::init() () from
/usr/lib64/lib-org-apache-jasper-4.1.27.so
(More stack frames follow...)

I've seen this before, and not always on the admin webapp IIRC. 
Anyway, org::w3c::dom::NodeList::class$ is the name of the Class
object for this class.  It is _not_ a function, so something is making
us execute random data.

Bryce McKinlay spake thusly:
A segfault from a class$ symbol likely means that the IP jumped to an
invalid address. ie: an attempt was made to branch/call to an address
that isn't a real function. This could happen due to bugs in dispatch
code or Method.invoke(), for example.
Comment 3 Gary Benson 2004-04-15 08:22:17 EDT
Ok, this is call that ends up trying to execute
org::w3c::dom::NodeList::class$:

diff -u -r1.1.1.1 ParserUtils.java
--- jasper/src/share/org/apache/jasper/xmlparser/ParserUtils.java       
+++ jasper/src/share/org/apache/jasper/xmlparser/ParserUtils.java       
@@ -261,7 +261,9 @@
                 if (child instanceof Comment)
                     continue;
                 if (child instanceof Text) {
+                    System.out.println("ParserUtils.convert: 1");
                     String body = ((Text) child).getData();
+                    System.out.println("ParserUtils.convert: 2");
                     if (body != null) {
                         body = body.trim();
                         if (body.length() > 0)

The child object is a org.apache.xerces.dom.DeferredTextImpl which
exists in this baffling class heirachy:

org.apache.xerces.dom.NodeImpl
  |        ··· org.w3c.dom.Node
  |        ··· org.w3c.dom.NodeList
  |        ··· org.w3c.dom.events.EventTarget
  |        ··· java.lang.Cloneable
  |        ··· java.io.Serializable
  |
org.apache.xerces.dom.ChildNode
  |
org.apache.xerces.dom.CharacterDataImpl 
  |        ··· org.w3c.dom.CharacterData
  |                ··· org.w3c.dom.Node
  |        ··· org.w3c.dom.Text
  |                ··· org.w3c.dom.CharacterData
  |                        ··· org.w3c.dom.Node
  |
org.apache.xerces.dom.TextImpl
  |
org.apache.xerces.dom.DeferredTextImpl
           ··· org.apache.xerces.dom.DeferredNode
                   ··· org.w3c.dom.Node

The method that should be called is
org::apache::xerces::dom::CharacterDataImpl::getData()
Comment 4 Gary Benson 2004-04-16 11:32:52 EDT
This was just libgcj version skew :-/

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