DO NOT REPLY [Bug 46211] Synchronization fault in FontCache
https://issues.apache.org/bugzilla/show_bug.cgi?id=46211 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Glenn Adams gl...@skynav.com 2012-04-01 06:43:13 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- 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 Andreas L. Delmelle [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-11-17 10:19:44 PST --- No further feedback received on fop-dev@, so changes committed to FOP Trunk in r718309 ( https://svn.apache.org/viewcvs.cgi?view=revrev=718309 ). Thanks for reporting! -- 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 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.
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 snip / ... 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 --- 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.
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 #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.
