JDK-6839599 : JVM crash while profiling Tomcat and Liferay
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs16
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_2.6
  • CPU: x86
  • Submitted: 2009-05-11
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u18Fixed 7Fixed hs16Fixed
Description
This is JVM crash caused by profiling of Tomcat & Liferay. 
Steps to reproduce:
1) Download NetBeans 6.7 beta or VisualVM
2) Download the Liferay Tomcat bundle from http://downloads.sourceforge.net/lportal/liferay-portal-tomcat-6.0-5.1.2.zip
3) Unpack the zip file and start Tomcat
4) Wait till the tomcat is fully started
5) Try to attach to the running Tomcat using "Dynamic Attach" (either using VisualVM or NetBeans, same behavior)

This bug was originally reported against NetBeans Profiler.
Original report is here: http://www.netbeans.org/issues/show_bug.cgi?id=150370

JVM crashes with:
Error: assert(sym != __null,"SymbolHashMap::find_entry - symbol is NULL") in constantPoolOop.cpp

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/47ffceb239d0
20-05-2009

EVALUATION Surprisingly the problem is caused by incorrectly encoded JVM_CONSTANT_Utf8 in constant pool of the specific classfile (it is org.apache.xerces.impl.xpath.regex.ParserForXMLSchema). It contains constant string private static final String DIGITS = "09\u0660\u0669\u06F0\u06F9\u0966\u096F\u09E6\u09EF\u0A66\u0A6F\u0AE6\u0AEF" +"\u0B66\u0B6F\u0BE7\u0BEF\u0C66\u0C6F\u0CE6\u0CEF\u0D66\u0D6F\u0E50\u0E59\u0ED0\u0ED9" +"\u0F20\u0F29"; which is encoded in classfile as: 30 39 e0 99 a0 e0 99 a9 e0 9b b0 e0 9b b9 e0 a5 |09..............| a6 e0 a5 af e0 a7 a6 e0 a7 af e0 a9 a6 e0 a9 af |................| e0 ab a6 e0 ab af e0 ad a6 e0 ad af e0 af a7 e0 |................| af af e0 b1 a6 e0 b1 af e0 b3 a6 e0 b3 af e0 b5 |................| a6 e0 b5 af e0 b9 90 e0 b9 99 e0 bb 90 e0 bb 99 |................| e0 bc a0 e0 bc a9 Note that third character (\u0660) in DIGITS string is encoded using three bytes (e0 99 a0), but it should be encoded using only two bytes (d9 a0). When such classfile is read by VM, it stores this UTF-8 string in symbol table via oopFactory::new_symbols() in ClassFileParser::parse_constant_pool_entries(). When the constant string represented by this symbol is accessed, it is converted to interned String object in constantPoolOopDesc::string_at_impl(). Now when profiler wants classfile for ParserForXMLSchema, JvmtiClassFileReconstituter::write_class_file_format() invokes constantPoolOopDesc::copy_cpool_bytes(). This code in case of JVM_CONSTANT_String gets the UTF-8 from the interned String object and this UTF-8 string is encoded correctly and uses two bytes (d9 a0) to encode third character. Now this UTF-8 string is used to look-up corresponding symbol in SymbolTable - but symbol table contains UTF-8 string from the classfile, which does not match the correct UTF-8 string from the interned String object. Therefor symbolOop sym = SymbolTable::lookup_only(str, (int) strlen(str), hash); returns null and assert is subsequently thrown from idx1 = tbl->symbol_to_value(sym); I was thinking about several possible fixes. Since the problem is caused by incorrectly generated classfile (probably by jikes) and it is very rare, I choose to use brute-force search through 'tbl' when SymbolTable::lookup_only() returns NULL. This way there is no memory or CPU overhead added by the fix for the case, where classfile is OK. Proposed fix is attached. Lines with // DEBUG suffix will be deleted. I used them for debugging the issue. The broken classfile can be found in http://downloads.sourceforge.net/lportal/liferay-portal-tomcat-6.0-5.1.2.zip Unzip liferay-portal-tomcat-6.0-5.1.2.zip file and org.apache.xerces.impl.xpath.regex.ParserForXMLSchema.class is in ./lib/ext/xercesImpl.jar
11-05-2009