DO NOT REPLY [Bug 46211] Synchronization fault in FontCache
https://issues.apache.org/bugzilla/show_bug.cgi?id=46211 --- Comment #4 from Andreas L. Delmelle <[EMAIL PROTECTED]> 2008-11-14 12:06:44 PST --- Created an attachment (id=22875) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22875) Patch proposal Added the proposed changes (including some other minor details, like simplification of conditionals) The one thing I'm not sure about: we cannot combine 'final' and 'transient' as modifiers, since this would mean that the variable would always be null, apart from the very first time the cache is instantiated. When the cache is serialized once, changeLock is not written to the stream (transient), but is also never initialized again upon deserialization... (weird that this combination is actually allowed in Java) In the patch, I've restricted it to 'final', since I don't really see why we would not serialize the lock together with the cache. Alternative would be to perform the assignment in yet another synchronized block (synchronized on the FontCache itself?) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46211] Synchronization fault in FontCache
https://issues.apache.org/bugzilla/show_bug.cgi?id=46211 --- Comment #3 from Andreas L. Delmelle <[EMAIL PROTECTED]> 2008-11-14 10:39:15 PST --- (In reply to comment #2) > no, i didn't tried it - but it seems quite obvious. OK, thanks for the feedback. > 1. it happens only when two threads have failed to load the font properly, > which is seldom enough by itself. and this got to happen to those threads in > this special order - one thread faile, tried to call isFailedFont, but got > outrun by another thread which grabs the changeLock ... Yep. A classic example of what is known as a 'race condition'. Unless the check is moved into the synchronized block as you suggest, this is bound to lead to trouble in some exceptional cases. > so, i suggest changing the "if" and "synchronized" order as in my previous > comment AND making changeLock final and initializing it along with that. > OK, will do. Just waiting for some feedback on fop-dev@ to see if I've overlooked anything. If not, then the changes will be committed in a few days. Thanks for tracking this and reporting the bug! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46211] Synchronization fault in FontCache
https://issues.apache.org/bugzilla/show_bug.cgi?id=46211 --- Comment #2 from ilj <[EMAIL PROTECTED]> 2008-11-14 10:30:21 PST --- no, i didn't tried it - but it seems quite obvious. and anyway - i will not be able to reproduce that easily for two reasons: 1. it happens only when two threads have failed to load the font properly, which is seldom enough by itself. and this got to happen to those threads in this special order - one thread faile, tried to call isFailedFont, but got outrun by another thread which grabs the changeLock ... 2. the font loading issue, which causeв this bug in my case was quickly fixed. and i really don't want to break that again :-) so, i suggest changing the "if" and "synchronized" order as in my previous comment AND making changeLock final and initializing it along with that. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: DO NOT REPLY [Bug 46211] Synchronization fault in FontCache
On 14 Nov 2008, at 19:12, [EMAIL PROTECTED] wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=46211 ... there seems to be another problem: changeLock is not a 'final' variable, nor is it declared 'volatile'. As a consequence: a) since it is neither final nor volatile, it is not guaranteed to be properly initialized (some threads may see 'null' instead of the Object instance) b) since it is not final, it is theoretically possible to re-assign the changeLock member to a different instance, which would lead to unpredictable behavior. It is possible for two threads to enter the synchronized block, since they have each locked a separate instance. Looking closer at the code, changeLock is only re-assigned in case of a call to the private FontCache.readObject() method. Since this method does not seem to be used, maybe making the member final would make sense... OTOH, I'm not the creator of this class, hence why I'm asking first: Does anyone see a potential problem with the proposed change? * removal of the unused readObject() * changing the changeLock member to become final * the small change proposed by the reporter This should resolve any multi-threading weirdness, IIC. WDYT? Anyone? Andreas
DO NOT REPLY [Bug 46211] Synchronization fault in FontCache
https://issues.apache.org/bugzilla/show_bug.cgi?id=46211 Andreas L. Delmelle <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Andreas L. Delmelle <[EMAIL PROTECTED]> 2008-11-14 10:12:09 PST --- I think the gist is correct. Have you tried changing it? Does it resolve the issue if you do? Reason I'm asking is that there seems to be another problem: changeLock is not a 'final' variable, nor is it declared 'volatile'. As a consequence: a) since it is neither final nor volatile, it is not guaranteed to be properly initialized (some threads may see 'null' instead of the Object instance) b) since it is not final, it is theoretically possible to re-assign the changeLock member to a different instance, which would lead to unpredictable behavior. It is possible for two threads to enter the synchronized block, since they have each locked a separate instance. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46211] New: Synchronization fault in FontCache
https://issues.apache.org/bugzilla/show_bug.cgi?id=46211
Summary: Synchronization fault in FontCache
Product: Fop
Version: 0.95
Platform: PC
OS/Version: Linux
Status: NEW
Severity: minor
Priority: P2
Component: fonts
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]
I have an application which renders a lot of PDFs using several threads. We had
an issue recently, concerning font loading. While investigating this stack
trace:
java.lang.NullPointerException
at org.apache.fop.fonts.FontCache.isFailedFont(FontCache.java:294)
at org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:179)
at
org.apache.fop.render.PrintRendererConfigurator.addFontInfoListFromFileList(PrintRendererConfigurator.java:233)
at
org.apache.fop.render.PrintRendererConfigurator.buildFontListFromConfiguration(PrintRendererConfigurator.java:140)
at
org.apache.fop.render.PrintRendererConfigurator.configure(PrintRendererConfigurator.java:95)
at
org.apache.fop.render.pdf.PDFRendererConfigurator.configure(PDFRendererConfigurator.java:71)
at
org.apache.fop.render.RendererFactory.createRenderer(RendererFactory.java:187)
at org.apache.fop.area.RenderPagesModel.(RenderPagesModel.java:68)
at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:127)
at org.apache.fop.area.AreaTreeHandler.(AreaTreeHandler.java:102)
at
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:224)
at org.apache.fop.fo.FOTreeBuilder.(FOTreeBuilder.java:100)
at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:100)
at org.apache.fop.apps.Fop.(Fop.java:78)
at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:247)
I have found a possible synchronization fault in FontCache method:
== Java code ==
public boolean isFailedFont(String embedUrl, long lastModified) {
if (failedFontMap.containsKey(embedUrl)) {
synchronized (changeLock) {
long failedLastModified =
((Long)failedFontMap.get(embedUrl)).longValue();
if (lastModified != failedLastModified) {
// this font has been changed so lets remove it
// from failed font map for now
failedFontMap.remove(embedUrl);
changed = true;
}
}
return true;
}
return false;
}
== end Java code ==
to my opinion, it shall be like this:
== Java code ==
public boolean isFailedFont(String embedUrl, long lastModified) {
synchronized (changeLock) {
if (failedFontMap.containsKey(embedUrl)) {
long failedLastModified =
((Long)failedFontMap.get(embedUrl)).longValue();
if (lastModified != failedLastModified) {
// this font has been changed so lets remove it
// from failed font map for now
failedFontMap.remove(embedUrl);
changed = true;
}
return true;
}
return false;
}
}
== end Java code ==
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
No Page Numbering in PDF
I am converting xhtml to PDF and PDF has page numbers inserted in it. But I dont want page numbers in the PDF. Does anybody know how to remove the page numbers or where in PDF does FOP embed Page Numbers. -- View this message in context: http://www.nabble.com/No-Page-Numbering-in-PDF-tp20498358p20498358.html Sent from the FOP - Dev mailing list archive at Nabble.com.
swt-renderer
Jeremias, thank you for your hints. We are going to investigate the branch and leave a message here when we have more detailed questions. Sebastian > Please consider subscribing to the fop-dev mailing list. That way I > don't have to moderate your posts each time and CC you. ;-) > -- Dipl.-Ing. Sebastian Fuchs Walter-Arnold-Straße 8 01219 Dresden fon: +49-(0)351-2728098 mobile: +49-(0)176-96338376 icq: 114494140
