You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Julien Aymé <ju...@gmail.com> on 2011/01/31 10:38:28 UTC
Re: Concurrent modification exception getting an instance of ICC_Profile
It seems that you just found out a race condition in
ProfileDeferralMgr. (A quick view on any decompiler show that a race
condition can occur when :
- Thread A enters registerDeferral, deferring is still true, thread A
checks !deffering ->OK
- Thread B enters activateProfiles, set deferring to false, calls
vector.iterator()
- Thread A adds new ProfileActivator in the vector
- Thread B calls iterator.next() -> CME
It seems that a similar issue was encountered an fixed in Fop 0.95:
http://www.mail-archive.com/fop-dev@xmlgraphics.apache.org/msg11808.html
Maybe we should check where ICC_Profile.getInstance is used on FOP
codebase and synchronize this method (sync on ICC_Profile.class ?)
You could try to submit a bug to sun bug database, since there is no
indication that ICC_Profile.getInstance is not thread-safe (at least
it could be documented) :-)
HTH,
Julien
2011/1/31 Alexios Giotis <al...@gmail.com>:
> Hi,
>
> I occasionally get the exception below using java version "1.6.0_21", 64-Bit Server VM and FOP 1.0 to transform FOP intermediate format to Postscript with more than one threads. Of course, each thread uses a new instance of org.apache.fop.render.intermediate.util.IFConcatenator. Any ideas why calling java.awt.color.ICC_Profile.getInstance() throws java.util.ConcurrentModificationException ?
>
>
> Caused by: java.util.ConcurrentModificationException
> at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
> at java.util.AbstractList$Itr.next(Unknown Source)
> at sun.awt.color.ProfileDeferralMgr.activateProfiles(Unknown Source)
> at java.awt.color.ICC_Profile.getInstance(Unknown Source)
> at org.apache.xmlgraphics.image.loader.impl.ImageLoaderRawJPEG.buildICCProfile(ImageLoaderRawJPEG.java:236)
> at org.apache.xmlgraphics.image.loader.impl.ImageLoaderRawJPEG.loadImage(ImageLoaderRawJPEG.java:198)
> at org.apache.xmlgraphics.image.loader.pipeline.ImageProviderPipeline.execute(ImageProviderPipeline.java:154)
> at org.apache.xmlgraphics.image.loader.pipeline.ImageProviderPipeline.execute(ImageProviderPipeline.java:99)
> at org.apache.xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:268)
> at org.apache.fop.render.intermediate.AbstractIFPainter.drawImageUsingImageHandler(AbstractIFPainter.java:143)
> at org.apache.fop.render.ps.PSPainter.drawImageUsingImageHandler(PSPainter.java:167)
> at org.apache.fop.render.intermediate.AbstractIFPainter.drawImageUsingURI(AbstractIFPainter.java:270)
> at org.apache.fop.render.ps.PSPainter.drawImage(PSPainter.java:185)
> at org.apache.fop.render.intermediate.IFParser$Handler$ImageHandler.endElement(IFParser.java:676)
> at org.apache.fop.render.intermediate.IFParser$Handler.endElement(IFParser.java:352)
> at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102)
> at org.xml.sax.helpers.XMLFilterImpl.endElement(Unknown Source)
> at com.idocs.export2.placeholder.PlaceholderFilter.endElement(PlaceholderFilter.java:61)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
> at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.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.xml.sax.helpers.XMLFilterImpl.parse(Unknown Source)
> at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
> at org.apache.fop.render.intermediate.IFParser.parse(IFParser.java:104)
> at org.apache.fop.render.intermediate.util.IFConcatenator.appendDocument(IFConcatenator.java:102)
>
>
>
> Thanks,
> Alexis Giotis
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Concurrent modification exception getting an instance of ICC_Profile
Posted by Alexios Giotis <al...@gmail.com>.
Andrea, Julien and Jeremia,
Thank you all for your immediate actions. I have created internally a copy of FOP 1.0 and I merge there a small number of issues that we encounter. Tomorrow I will merge your changes related to this, continue the tests with many and big documents running in parallel and come back if I find something else. The case with the ICC_Profile was at least counter intuitive...
Regards,
Alexios Giotis
On Feb 1, 2011, at 10:27 PM, Andreas Delmelle wrote:
> On 01 Feb 2011, at 13:44, Julien Aymé wrote:
>
> Alexios,
>
> FWIW: patches have been applied to XMLGraphics and FOP Trunk that should address this issue.
> If you are at liberty to download FOP Trunk or can try running it against a nightly build (http://ci.apache.org/projects/xmlgraphics/fop/snapshots/), we would be very interested in finding out whether the behavior is corrected.
>
> Thanks!
>
> Regards,
>
> Andreas
> ---
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Concurrent modification exception getting an instance of ICC_Profile
Posted by Andreas Delmelle <an...@telenet.be>.
On 01 Feb 2011, at 13:44, Julien Aymé wrote:
Alexios,
FWIW: patches have been applied to XMLGraphics and FOP Trunk that should address this issue.
If you are at liberty to download FOP Trunk or can try running it against a nightly build (http://ci.apache.org/projects/xmlgraphics/fop/snapshots/), we would be very interested in finding out whether the behavior is corrected.
Thanks!
Regards,
Andreas
---
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Concurrent modification exception getting an instance of ICC_Profile
Posted by Julien Aymé <ju...@gmail.com>.
Hi Andreas,
You're right, I had forgotten that this was an AWT issue, and we
should be the one to fix the issue.
So thanks for the patch :-)
Julien
2011/2/1 Andreas Delmelle <an...@telenet.be>:
> On 31 Jan 2011, at 10:38, Julien Aymé wrote:
>
> Hi Alexios, Julien,
>
>> 2011/1/31 Alexios Giotis <al...@gmail.com>:
>
>>> Any ideas why calling java.awt.color.ICC_Profile.getInstance() throws java.util.ConcurrentModificationException ?
>
>> It seems that you just found out a race condition in
>> ProfileDeferralMgr.
> <snip />
>
> I don't think it was meant for concurrent usage, but could be wrong. I was always under the impression that AWT expects the calling code to synchronize wherever appropriate. We have noticed similar issues in the past, with the AWT font-related classes.
> AFAIK, AWT makes no claim whatsoever about being thread-safe, so the issue should be fixed on our end.
>
>> It seems that a similar issue was encountered an fixed in Fop 0.95:
>> http://www.mail-archive.com/fop-dev@xmlgraphics.apache.org/msg11808.html
>>
>> Maybe we should check where ICC_Profile.getInstance is used on FOP
>> codebase and synchronize this method (sync on ICC_Profile.class ?)
>
> IIC, the issue here arises from within XMLGraphics. There are, however, still two distinct places in FOP's code that can trigger the issue (ColorSpaceCache.getString() and PDFRenderingUtil.addDefaultOutputProfile()). Those, I have taken care of in the patch attached to Bugzilla 50698 (https://issues.apache.org/bugzilla/show_bug.cgi?id=50698), which will likely find its way into Trunk soon.
>
> A similar fix would still need to make it into XMLGraphics in order to avoid the race condition in this particular case.
>
>
> Regards
>
> Andreas
> ---
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Concurrent modification exception getting an instance of ICC_Profile
Posted by Andreas Delmelle <an...@telenet.be>.
On 31 Jan 2011, at 10:38, Julien Aymé wrote:
Hi Alexios, Julien,
> 2011/1/31 Alexios Giotis <al...@gmail.com>:
>> Any ideas why calling java.awt.color.ICC_Profile.getInstance() throws java.util.ConcurrentModificationException ?
> It seems that you just found out a race condition in
> ProfileDeferralMgr.
<snip />
I don't think it was meant for concurrent usage, but could be wrong. I was always under the impression that AWT expects the calling code to synchronize wherever appropriate. We have noticed similar issues in the past, with the AWT font-related classes.
AFAIK, AWT makes no claim whatsoever about being thread-safe, so the issue should be fixed on our end.
> It seems that a similar issue was encountered an fixed in Fop 0.95:
> http://www.mail-archive.com/fop-dev@xmlgraphics.apache.org/msg11808.html
>
> Maybe we should check where ICC_Profile.getInstance is used on FOP
> codebase and synchronize this method (sync on ICC_Profile.class ?)
IIC, the issue here arises from within XMLGraphics. There are, however, still two distinct places in FOP's code that can trigger the issue (ColorSpaceCache.getString() and PDFRenderingUtil.addDefaultOutputProfile()). Those, I have taken care of in the patch attached to Bugzilla 50698 (https://issues.apache.org/bugzilla/show_bug.cgi?id=50698), which will likely find its way into Trunk soon.
A similar fix would still need to make it into XMLGraphics in order to avoid the race condition in this particular case.
Regards
Andreas
---
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org