Closed Bug 898569 Opened 11 years ago Closed 10 years ago

Always have the decoder lock when using mInDecoder

Categories

(Core :: Graphics: ImageLib, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: joe, Unassigned)

References

Details

Attachments

(1 file)

It's not safe to use mInDecoder without holding the lock. While I'm pretty sure it's obsolete (bug 854506), for now it still exists so it should at least be safe.
Blocks: 716140
This adds locks everywhere we didn't have them before, and/or moves things.

(I accidentally committed the header file comment that notes mInDecoder is locked in bug 887466.)

 https://tbpl.mozilla.org/?tree=Try&rev=cc32840d707e
Attachment #781861 - Flags: review?(seth)
Comment on attachment 781861 [details] [diff] [review]
always lock when you touch mInDecoder

Review of attachment 781861 [details] [diff] [review]:
-----------------------------------------------------------------

::: image/src/RasterImage.cpp
@@ +817,5 @@
> +  {
> +    MutexAutoLock lock(mDecodingMutex);
> +    if (mInDecoder && (aFlags & imgIContainer::FLAG_SYNC_DECODE))
> +      return NS_ERROR_FAILURE;
> +  }

If you release the lock after reading mInDecoder, what's to stop another thread from immediately setting mInDecoder to true and violating the preconditions of the rest of this method? Everything that requires mInDecoder to remain false to behave correctly needs to be inside the locked region, which may require some code motion.

@@ +882,5 @@
> +  {
> +    MutexAutoLock lock(mDecodingMutex);
> +    if (mInDecoder && (aFlags & imgIContainer::FLAG_SYNC_DECODE))
> +      return NS_ERROR_FAILURE;
> +  }

Looks like the same issue here.

@@ +2597,5 @@
> +  {
> +    MutexAutoLock lock(mDecodingMutex);
> +    if (mInDecoder && (aFlags & imgIContainer::FLAG_SYNC_DECODE))
> +      return NS_ERROR_FAILURE;
> +  }

Same issue here too.
Attachment #781861 - Flags: review?(seth) → review-
It's a good point, but I'm not sure whether we actually have anything that requires it; this might actually be a "you're not allowed to do it" error rather than a "we will break if you don't do this" error.

I'll think more about this, though.
If it really won't break anything, maybe it should just be an assertion?
Assignee: joe → nobody
Taking.
Assignee: nobody → rclickenbrock
Status: NEW → ASSIGNED
mInDecoder was removed entirely by Bug 1089046, so this is no longer necessary.
Assignee: rclickenbrock → nobody
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: