[ http://issues.apache.org/jira/browse/XALANJ-2046?page=history ]
Carlo Marchiori updated XALANJ-2046:
------------------------------------
Attachment: src.zip
Hi,
I have found that the problem is due to Eclipse 3.0.? compiler.
If you download Xalan 2.6.0 sources, recompile them with Eclipse
and then run the test I attached, you get a heapdump and the jvm
hangs, at least on the platform described in the enviroment described
in the first post of this bug.
Instead, if you use Sun jdk.1.4.2 to compile xalan, everything works
fine.
Carlo.
> StringBufferPool + FastStringBuffer are not thread safe
> -------------------------------------------------------
>
> Key: XALANJ-2046
> URL: http://issues.apache.org/jira/browse/XALANJ-2046
> Project: XalanJ2
> Type: Bug
> Versions: 2.6
> Environment: OS Name Microsoft(R) Windows(R) Server 2003, Enterprise Edition
> Version 5.2.3790 Build 3790
> OS Manufacturer Microsoft Corporation
> System Type X86-based PC
> 4 processors
> Processor x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3056 Mhz
> Processor x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3056 Mhz
> Processor x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3056 Mhz
> Processor x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3056 Mhz
> J2EE Server Websphere version 5.2
> Java version = J2RE 1.4.1 IBM Windows 32 build cn1411-20031011b (JIT enabled:
> jitc), Java Compiler = jitc, Java VM name = Classic VM
> Reporter: Carlo Marchiori
> Attachments: src.zip
>
> org.apache.xml.utils.StringBufferPool + org.apache.xml.utils.FastStringBuffer
> are not thread safe.
> Under heavy load and after many invocation (I guess right after bytecode is
> compiled into machine code) I get the following exception:
> Caused by: java.lang.NegativeArraySizeException
> at java.lang.StringBuffer.<init>(StringBuffer.java(Compiled Code))
> at
> org.apache.xml.utils.FastStringBuffer.toString(FastStringBuffer.java:433)
> at org.apache.xalan.templates.AVT.<init>(AVT.java(Compiled Code))
> at
> org.apache.xalan.processor.XSLTAttributeDef.processAVT_QNAME(XSLTAttributeDef.java(Compiled
> Code))
> at
> org.apache.xalan.processor.XSLTAttributeDef.processValue(XSLTAttributeDef.java(Compiled
> Code))
> at
> org.apache.xalan.processor.XSLTAttributeDef.setAttrValue(XSLTAttributeDef.java(Compiled
> Code))
> at
> org.apache.xalan.processor.XSLTElementProcessor.setPropertiesFromAttributes(XSLTElementProcessor.java(Compiled
> Code))
> at
> org.apache.xalan.processor.XSLTElementProcessor.setPropertiesFromAttributes(XSLTElementProcessor.java(Inlined
> Compiled Code))
> at
> org.apache.xalan.processor.ProcessorTemplateElem.startElement(ProcessorTemplateElem.java(Compiled
> Code))
> at
> org.apache.xalan.processor.StylesheetHandler.startElement(StylesheetHandler.java(Compiled
> Code))
> at
> org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java(Compiled
> Code))
> at
> org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement(XMLNamespaceBinder.java(Compiled
> Code))
> at
> org.apache.xerces.impl.XMLNamespaceBinder.startElement(XMLNamespaceBinder.java(Compiled
> Code))
> at
> org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java(Compiled
> Code))
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java(Compiled
> Code))
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java(Compiled
> Code))
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java(Compiled
> Code))
> at
> org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524)
> at
> org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580)
> at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
> at
> org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1169)
> at
> org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:795)
> ... 37 more
> I managed to see that the instance fields of the FastStringBuffer instance
> are set to random values (negative in particular), and so the exception
> occurs.
> I think that the problem is due to incorrect coding.
> In fact the code is equivalent to the following
> ----------------------------------------------------------
> synchronized (...)
> {
> //acquire an fsb instance from static pool
> }
>
> //write to fsb instance fields
>
> synchronized (...)
> {
> //release the fsb instance into the static pool
> }
> ----------------------------------------------------------
>
> When the first synchronized block ends the local thread cache is flushed
> to main memory. When the second synchronized block begins the local thread
> cache
> is refreshed from main memory, but in this way all intervening writes may be
> lost.
> I propose the StringBufferPool to have the lifetime of a transformation and
> to belong to a single thread. I suggest further long running optimizations to
> be left to the underlying plaftorm.
> Carlo.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
