Closed Bug 1666704 Opened 1 year ago Closed 1 year ago

IDXGIKeyedMutex key be released even when not locked.

Categories

(Core :: Graphics: Layers, defect)

Unspecified
Windows
defect

Tracking

()

RESOLVED FIXED
83 Branch
Tracking Status
firefox83 --- fixed

People

(Reporter: jya, Assigned: jya)

References

Details

Attachments

(1 file)

Saw the issue as I was investigating bug 1666698. There's a similar bug here: bug 1664063, though I'm not sure if this is the same exactly.

The utility class AutoCheckLockD3D11Texture is used to determine if a texture was locked or not.
It does so using IDXGIKeyedMutex::AcquireSync and giving a timeout value of 0.

According to Microsoft documentation [1]:
"If this value is set to zero, the AcquireSync method will test to see if the keyed mutex has been released and returns immediately. If this value is set to INFINITE, the time-out interval will never elapse."

Now, the destructor of this RAII class will release the mutex even if it failed to lock it and that can't be good.

[1] https://docs.microsoft.com/en-us/windows/win32/api/dxgi/nf-dxgi-idxgikeyedmutex-acquiresync

Regressions: 1479175

An additional, more serious issue is that if AcquireSync is called on a locked surface it will returns WAIT_TIMEOUT which is a positive value ; as such SUCCEEDED(WAIT_TIMEOUT ) will always return true.

So even if the texture is actually locked, it will be marked as unlocked rendering the usage of that method totally invalid seeing that the surface will be recycled anyway.

And more importantly, don't report a failure to sync (WAIT_TIMEOUT) as having succeeded.

See Also: → 1666987
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/feff80ad3151
Only release the sync if it was acquired in the first place. r=bas
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch
You need to log in before you can comment on or make changes to this bug.