Assertion failure: [GFX1]: Texture deallocated too late during shutdown, at gfx/2d/Logging.h:518

RESOLVED FIXED

Status

()

P1
normal
Rank:
17
RESOLVED FIXED
a year ago
6 months ago

People

(Reporter: florian, Unassigned)

Tracking

(Blocks: 1 bug, {assertion, intermittent-failure, memory-leak})

54 Branch
assertion, intermittent-failure, memory-leak
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox52 unaffected, firefox-esr52 unaffected, firefox53 unaffected, firefox54 disabled, firefox55 disabled)

Details

(Whiteboard: [stockwell fixed:product])

Attachments

(1 attachment)

See failures in https://treeherder.mozilla.org/#/jobs?repo=try&revision=b9b278db557d on the new browser_devices_get_user_media_multi_process.js test.

I'm going to have to disable it for "e10s && debug" to land bug 1325049.
From the following, VideoDevice, MediaDevice, and MediaEngineRemoteVideoSource were destroyed too late during ShutdownXPCOM. Then I don't think it is a gfx bug.
  https://treeherder.mozilla.org/logviewer.html#?job_id=84021642&repo=try&lineNumber=3178
:jesup, can you comment to the bug?
Flags: needinfo?(rjesup)
hmmm, we've had issues like this in the past.  Something is holding a MediaDevice until we're in final-CC, which may imply something was held "late" before it released during the shutdown sequence, and then in final-CC it was caught up with and killed (and caused this).

We could hack to to dump the held Images (mImage) in video sources on a shutdown observer, but that's a bandaid.

We could modify things to not give up on images until after final-CC - but this may be impossible, since likely we shut down critical elements before it.

We could hunt down why this was held until final-CC; that may not be easy, but if we can repro this with rr (probably so) this might be possible to figure out easily (solving may be more hard).

The interesting part here is something is holding a MediaDevice directly it appears.
Component: Graphics → WebRTC: Audio/Video
Flags: needinfo?(rjesup)
Rank: 17
Priority: -- → P1
I wonder if this is the same root cause for the leaks we're getting on Aurora ASAN runs since e10s-multi was enabled there.
https://treeherder.mozilla.org/logviewer.html#?job_id=88727603&repo=mozilla-aurora
status-firefox54: --- → affected
status-firefox55: --- → affected
Turns out the leaks have been there since this test landed, but LSAN leak checking is broken on trunk due to bug 1353858 :\. Per discussion with jesup, I'm going to skip the test on ASAN for now and he said he can investigate more next week.
status-firefox52: --- → unaffected
status-firefox53: --- → unaffected
status-firefox-esr52: --- → unaffected
Flags: needinfo?(rjesup)
Keywords: assertion, leave-open, mlk

Comment 6

a year ago
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/72c867371b30
Skip browser_devices_get_user_media_multi_process.js on ASAN due to leaks.
https://hg.mozilla.org/releases/mozilla-aurora/rev/2448220fff6b
status-firefox54: affected → disabled
status-firefox55: affected → disabled
1 failures in 814 pushes (0.001 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* autoland: 1

Platform breakdown:
* linux32: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1347625&startday=2017-06-12&endday=2017-06-18&tree=all

Updated

a year ago
Keywords: intermittent-failure
2 failures in 822 pushes (0.002 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* autoland: 2

Platform breakdown:
* linux64-qr: 1
* linux64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1347625&startday=2017-07-17&endday=2017-07-23&tree=all
10 failures in 1008 pushes (0.01 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* autoland: 8
* mozilla-inbound: 2

Platform breakdown:
* linux64-qr: 6
* linux32: 2
* linux64-stylo: 1
* linux64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1347625&startday=2017-07-24&endday=2017-07-30&tree=all
22 failures in 888 pushes (0.025 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* autoland: 14
* mozilla-inbound: 6
* mozilla-central: 2

Platform breakdown:
* linux64-qr: 14
* linux32: 7
* linux64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1347625&startday=2017-07-31&endday=2017-08-06&tree=all
24 failures in 901 pushes (0.027 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* autoland: 13
* mozilla-inbound: 10
* mozilla-central: 1

Platform breakdown:
* linux64-qr: 19
* linux64: 2
* linux64-stylo: 1
* linux64-ccov: 1
* linux32: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1347625&startday=2017-08-07&endday=2017-08-13&tree=all
6 failures in 949 pushes (0.006 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* autoland: 4
* mozilla-inbound: 2

Platform breakdown:
* linux64-qr: 4
* linux64-stylo: 1
* linux64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1347625&startday=2017-08-14&endday=2017-08-20&tree=all
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Whiteboard: [stockwell fixed:product]
Joel, this test is still being skipped on debug/ASAN. We should probably see if it still needs to be since the annotation in the manifest is point at this bug, now resolved.
Flags: needinfo?(rjesup) → needinfo?(jmaher)
I did a try push:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=33c9798c52eea36398a435e7afbb0d86f589e74d

you can see on osx and windows we hit this same assertion, but it looks to be ok on linux and asan- should we reopen this bug, or mark it as [stockwell disabled] ?
Flags: needinfo?(jmaher)
Let's file a new bug for the OSX/Win asserts then update the annotations to only skip on those platforms with a reference to the new bug.
Created attachment 8901170 [details] [diff] [review]
enable test for linux debug/asan
Attachment #8901170 - Flags: review?(ryanvm)
Comment on attachment 8901170 [details] [diff] [review]
enable test for linux debug/asan

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

::: browser/base/content/test/webrtc/browser.ini
@@ +10,5 @@
>  [browser_devices_get_user_media_anim.js]
>  [browser_devices_get_user_media_in_frame.js]
>  skip-if = debug # bug 1369731
>  [browser_devices_get_user_media_multi_process.js]
> +skip-if = debug && (os == "win" || os == "mac") # bug 1347625

Please reference bug 1393761 here instead of 1347625.
Attachment #8901170 - Flags: review?(ryanvm) → review+

Comment 21

a year ago
Pushed by jmaher@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/69c7fb127acf
enable browser_devices_get_user_media_multi_process.js for linux debug/asan. r=RyanVM
2 failures in 908 pushes (0.002 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* mozilla-inbound: 1
* autoland: 1

Platform breakdown:
* windows7-32: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1347625&startday=2017-08-21&endday=2017-08-27&tree=all
1 failures in 939 pushes (0.001 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* autoland: 1

Platform breakdown:
* windows7-32: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1347625&startday=2017-08-28&endday=2017-09-03&tree=all
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.