Bug 683848

Summary: tomcat5 startup problem: java.lang.UnsatisfiedLinkError: /usr/lib64/libtcnative-1.so.0.1.19 - wrong ELF class: ELFCLASS64 (since present in old version too)
Product: [JBoss] JBoss Enterprise Web Server 1 Reporter: Jan Ščotka <jscotka>
Component: Red Hat Enterprise Linux 5Assignee: Permaine Cheung <pcheung>
Status: CLOSED EOL QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 1.0.0CC: csutherl, jlieskov
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-04 14:51:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jan Ščotka 2011-03-10 13:52:58 UTC 
Description of problem:
Hi, when testing erratum RHSA-2011:10788-05 - Important: tomcat5 security update
On X86_64 in catalina.out log is traceback:
java.lang.UnsatisfiedLinkError: /usr/lib64/libtcnative-1.so.0.1.19: /usr/lib64/libtcnative-1.so.0.1.19: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch)
It is also in old version, so it is not a regression.

Hopefully it doesn't affect tomcat5 startup, after traceback tomcat is started up and seems to be fully working.

How reproducible:
100%

Steps to Reproduce:
1. service tomcat5 start 
2. cat  /var/log/tomcat5/catalina.out

Actual results:
java.lang.UnsatisfiedLinkError: /usr/lib64/libtcnative-1.so.0.1.19: /usr/lib64/libtcnative-1.so.0.1.19: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728) at java.lang.Runtime.loadLibrary0(Runtime.java:823) at java.lang.System.loadLibrary(System.java:1028) at org.apache.tomcat.jni.Library.<init>(Library.java:42) at org.apache.tomcat.jni.Library.initialize(Library.java:168) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.connector.Connector.setProtocol(Connector.java:620) at org.apache.catalina.connector.Connector.<init>(Connector.java:72) at org.apache.catalina.startup.ConnectorCreateRule.begin(ConnectorCreateRule.java:44) at org.apache.tomcat.util.digester.Rule.begin(Rule.java:153) at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1276) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1562) at org.apache.catalina.startup.Catalina.load(Catalina.java:490) at org.apache.catalina.startup.Catalina.load(Catalina.java:524) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:267) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) 

Expected results:
no traceback

Additional info:
Comment 1 Jan Lieskovsky 2011-03-10 14:05:25 UTC 
Potential reason of this issue might be the following:

Searching for the "ELFCLASS64 (Possible cause: architecture word width mismatch)" string brought:
[1] http://forums.oracle.com/forums/thread.jspa?threadID=651235

with explanation:

"Hi, The error message is pretty specific; you are running a 32-bit JVM trying
to load a 64-bit native shared library. That is not allowed. You need to run
the 64-bit JVM. If I recall correctly you need to give an argument something
like -d64 on the Java command line. Chris"

and yet:

Q: Could someone please tell me how to make -d64 option stick to the weblogic managed server jvm argument?

A: Update your JAVA_VM variable in commEnv.sh.
That should do it. JAVA_VM="-d64 -client"

Conclusion: So I would suspect, the above error should be reported as normal bug (since present also in old version), and it should be fixed by adding the "-d64" flag, when trying to load that "/usr/lib64/libtcnative-1.so.0.1.19" library.

Permaine, David, please correct me if the above is wrong and the issue has
different reason.

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team