Closed Bug 1284384 Opened 4 years ago Closed 4 years ago

Crash in mozilla::layers::TextureClient::Unlock

Categories

(Core :: Graphics: Layers, defect, critical)

x86
Windows
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla50
Tracking Status
firefox50 --- verified
firefox51 --- unaffected
firefox52 --- unaffected

People

(Reporter: ting, Assigned: nical)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-6d777cbe-2948-440d-b328-4eb2c2160704.
=============================================================

#42 of 20160703 windows nightly, 7 crashes from 6 installations.

Low volume now, but it's a null pointer dereferencing, if we can add a checker...
This seems right up your alley Nical. The only way I could see this happening is if we're using the shared surface workaround and Destroy gets called before Unlock. Which means we should probably deal with it (perhaps a simple nullcheck).
Assignee: nobody → nical.bugzilla
Seven crashes in Nightly 20160708030216, all from different installations.
Nical, see comment 1.
Flags: needinfo?(nical.bugzilla)
Blocks: 1285271
(In reply to Nicholas Nethercote [:njn] from comment #3)
> Nical, see comment 1.

This should be fixed in the next nightly (by preffing off the regressing feature in bug 1284721). I'll look into this before I reenable it.
Flags: needinfo?(nical.bugzilla)
The problem happens because a TextureClient is force-destroyed during the shutdown of gfx/ipc, and sadly something tries to unlock the Texture after that.

when this happens mData has been nulled out. It makes sense to clear the potential reference to the DrawTarget (mBorrowedDrawTarget) in Destroy, because keeping a DT around some data we are destroying is bad. This means that we don't need to check the other acces to mData in Unlock because mBorrowedDrawTarget will be null if mData is null.
Attachment #8774314 - Flags: review?(sotaro.ikeda.g)
Comment on attachment 8774314 [details] [diff] [review]
Don't crash if TextureClient::Destroy happens between lock and unlock

Looks good!
Attachment #8774314 - Flags: review?(sotaro.ikeda.g) → review+
Pushed by nsilva@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a99dade5a9b6
Don't crash if TextureClient::Destroy is called between Lock and Unlock. r=sotaro
https://hg.mozilla.org/mozilla-central/rev/a99dade5a9b6
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
I believe we can safely mark this verified fixed on Fx50, based on the crash
data available for the last 2 months.

  SIGNATURE   | mozilla::layers::TextureClient::Unlock
  ----------------------------------------------------
  CRASH STATS | http://tinyurl.com/z9jut2w
  ----------------------------------------------------
  OVERVIEW    | 0 crashes on nightly 52
	      | 0 crashes on nightly 51
	      | 0 crashes on aurora 51
	      | 2 crashes on nightly 50
	      | 1 crashes on aurora 50
	      | 0 crashes on beta 50
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.