Intermittent dom/browser-element/mochitest/test_browserElement_inproc_AudioPlayback.html, test_browserElement_inproc_BackForward.html | Assertion count 6 is greater than expected range 0-0 assertions.

RESOLVED FIXED in Firefox 56

Status

()

Core
DOM
P5
normal
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: Treeherder Bug Filer, Assigned: alwu)

Tracking

({intermittent-failure})

unspecified
mozilla56
intermittent-failure
Points:
---

Firefox Tracking Flags

(firefox56 fixed)

Details

(Whiteboard: [stockwell fixed:obsolete])

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments)

https://public-artifacts.taskcluster.net/H5PtdZDJTwqqVttETeYUsg/0/public/test_info//logcat-emulator-5554.log

01-23 09:34:37.345   788   808 I Gecko   : [Parent 788] ###!!! ASSERTION: AreDialogsEnabled() called without a top window?: 'Error', file /home/worker/workspace/build/src/dom/base/nsGlobalWindow.cpp, line 3329
01-23 09:34:37.355   788   808 I Gecko   : [Parent 788] ###!!! ASSERTION: AreDialogsEnabled() called without a top window?: 'Error', file /home/worker/workspace/build/src/dom/base/nsGlobalWindow.cpp, line 3329
01-23 09:34:37.355   788   808 I Gecko   : [Parent 788] ###!!! ASSERTION: AreDialogsEnabled() called without a top window?: 'Error', file /home/worker/workspace/build/src/dom/base/nsGlobalWindow.cpp, line 3329
01-23 09:34:37.355   788   808 I Gecko   : [Parent 788] ###!!! ASSERTION: AreDialogsEnabled() called without a top window?: 'Error', file /home/worker/workspace/build/src/dom/base/nsGlobalWindow.cpp, line 3329
01-23 09:34:37.355   788   808 I Gecko   : [Parent 788] ###!!! ASSERTION: AreDialogsEnabled() called without a top window?: 'Error', file /home/worker/workspace/build/src/dom/base/nsGlobalWindow.cpp, line 3329
01-23 09:34:37.804   788   808 D GeckoIdleService: Registering Idle observer callback
01-23 09:34:37.804   788   808 D GeckoIdleService: Register idle observer 0x5537c180 for 180 seconds
01-23 09:34:37.804   788   808 D GeckoIdleService: Register: adjusting next switch from -1 to 180 seconds
01-23 09:34:37.814   788   808 D GeckoIdleService: next timeout 179987 msec from now
01-23 09:34:37.814   788   808 D GeckoIdleService: SetTimerExpiryIfBefore: next timeout 179985 msec from now
01-23 09:34:37.814   788   808 D GeckoIdleService: reset timer expiry to 179994 msec from now
01-23 09:34:38.325   788   827 I Gecko   : [Parent 788] WARNING: waitpid failed pid:1375 errno:10: file /home/worker/workspace/build/src/ipc/chromium/src/base/process_util_posix.cc, line 276
01-23 09:34:38.535  1375  1388 I Gecko   : 
01-23 09:34:38.535  1375  1388 I Gecko   : ###!!! [Child][MessageChannel] Error: (msgtype=0x4400FC,name=PContent::Msg_AccumulateChildHistogram) Closed channel: cannot send/recv
01-23 09:34:38.535  1375  1388 I Gecko   : 
01-23 09:34:38.535  1375  1388 I Gecko   : [Child 1375] WARNING: MsgDropped in ContentChild: file /home/worker/workspace/build/src/dom/ipc/ContentChild.cpp, line 2143
01-23 09:34:38.555  1375  1388 I Gecko   : [Child 1375] WARNING: '!contentChild->SendAccumulateChildHistogram(accumulationsToSend)', file /home/worker/workspace/build/src/toolkit/components/telemetry/TelemetryIPCAccumulator.cpp, line 209
01-23 09:34:38.555  1375  1388 I Gecko   : [Child 1375] ###!!! ASSERTION: Potential deadlock detected:
01-23 09:34:38.555  1375  1388 I Gecko   : Cyclical dependency starts at
01-23 09:34:38.555  1375  1388 I Gecko   : Mutex : nsAppShell.Queue
01-23 09:34:38.555  1375  1388 I Gecko   : Next dependency:
01-23 09:34:38.555  1375  1388 I Gecko   : Mutex : StaticMutex
01-23 09:34:38.555  1375  1388 I Gecko   : Next dependency:
01-23 09:34:38.555  1375  1388 I Gecko   : Mutex : StaticMutex
01-23 09:34:38.555  1375  1388 I Gecko   : Next dependency:
01-23 09:34:38.555  1375  1388 I Gecko   : Mutex : TimerThread.mMonitor
01-23 09:34:38.555  1375  1388 I Gecko   : Next dependency:
01-23 09:34:38.555  1375  1388 I Gecko   : ReentrantMonitor : SharedThreadPool (currently acquired)
01-23 09:34:38.555  1375  1388 I Gecko   : Cycle completed at
01-23 09:34:38.555  1375  1388 I Gecko   : Mutex : nsAppShell.Queue
01-23 09:34:38.555  1375  1388 I Gecko   : Deadlock may happen for some other execution
01-23 09:34:38.555  1375  1388 I Gecko   : 
01-23 09:34:38.555  1375  1388 I Gecko   : : 'Error', file /home/worker/workspace/build/src/xpcom/glue/BlockingResourceBase.cpp, line 307
01-23 09:34:39.265  1375  1388 I Gecko   : [Child 1375] WARNING: NS_ENSURE_TRUE(maybeContext) failed: file /home/worker/workspace/build/src/xpcom/threads/nsThread.cpp, line 1004
Assignee: nobody → gbrown
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1332850

Comment 3

2 years ago
37 failures in 141 pushes (0.262 failures/push) were associated with this bug yesterday.  

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

Platform breakdown:
* android-4-3-armv7-api15: 25
* linux32: 8
* linux64: 3
* osx-10-10: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-01-27&endday=2017-01-27&tree=all
Because we break a lot of things in a lot of ways all at once, this wasn't actually just an Android bug from the test being enabled on Android, it also fails on other platforms.
Assignee: gbrown → nobody
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 5

2 years ago
15 failures in 45 pushes (0.333 failures/push) were associated with this bug yesterday.  

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

Platform breakdown:
* android-4-3-armv7-api15: 10
* osx-10-10: 2
* linux64: 2
* linux32: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-01-28&endday=2017-01-28&tree=all

Comment 6

2 years ago
79 failures in 749 pushes (0.105 failures/push) were associated with this bug in the last 7 days. 

This is the #21 most frequent failure this week. 

** This failure happened more than 50 times this week! Resolving this bug is a high priority. **

Repository breakdown:
* mozilla-inbound: 49
* autoland: 24
* mozilla-central: 4
* graphics: 2

Platform breakdown:
* android-4-3-armv7-api15: 57
* linux32: 10
* osx-10-10: 7
* linux64: 5

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-01-23&endday=2017-01-29&tree=all
while Android was the most offensive, we still have many other instances on linux and osx.

Comment 8

2 years ago
16 failures in 115 pushes (0.139 failures/push) were associated with this bug yesterday.  

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

Platform breakdown:
* linux32: 7
* osx-10-10: 5
* linux64: 4

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-01-30&endday=2017-01-30&tree=all
On linux and osx, we typically hit 6 to 10 instances of

[task 2017-01-31T00:38:25.842721Z] 00:38:25     INFO - TEST-START | dom/browser-element/mochitest/test_browserElement_inproc_AudioPlayback.html
[task 2017-01-31T00:38:25.870136Z] 00:38:25     INFO - [Parent 4959] ###!!! ASSERTION: AreDialogsEnabled() called without a top window?: 'Error', file /home/worker/workspace/build/src/dom/base/nsGlobalWindow.cpp, line 3338
[task 2017-01-31T00:38:56.350181Z] 00:38:56     INFO - #01: nsGlobalWindow::AlertOrConfirm [dom/base/nsGlobalWindow.cpp:6941]
[task 2017-01-31T00:38:56.351249Z] 00:38:56     INFO - 
[task 2017-01-31T00:38:56.351327Z] 00:38:56     INFO - #02: mozilla::dom::WindowBinding::alert [obj-firefox/dom/bindings/WindowBinding.cpp:2595]
[task 2017-01-31T00:38:56.352025Z] 00:38:56     INFO - 
[task 2017-01-31T00:38:56.352118Z] 00:38:56     INFO - #03: mozilla::dom::WindowBinding::genericMethod [obj-firefox/dom/bindings/WindowBinding.cpp:15425]
[task 2017-01-31T00:38:56.352755Z] 00:38:56     INFO - 
[task 2017-01-31T00:38:56.353453Z] 00:38:56     INFO - #04: ??? (???:???)
I don't see any recent changes that look related to this frequent intermittent failure. The AreDialogsEnabled() assertion has been in place for a long time and doesn't seem to be hit during other tests. 

Andrew - Would it be okay to allow assertions in this test (mark with something like expectAssertions(0,10)) ?
Flags: needinfo?(overholt)

Comment 11

2 years ago
19 failures in 119 pushes (0.16 failures/push) were associated with this bug yesterday.  

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

Platform breakdown:
* linux32: 9
* linux64: 8
* osx-10-10: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-01-31&endday=2017-01-31&tree=all
(In reply to Geoff Brown [:gbrown] from comment #10)
> I don't see any recent changes that look related to this frequent
> intermittent failure. The AreDialogsEnabled() assertion has been in place
> for a long time and doesn't seem to be hit during other tests. 
> 
> Andrew - Would it be okay to allow assertions in this test (mark with
> something like expectAssertions(0,10)) ?

I don't know but Gabor or maybe baku probably do.
Flags: needinfo?(overholt)
Flags: needinfo?(gkrizsanits)
Flags: needinfo?(amarchesini)

Comment 13

2 years ago
16 failures in 135 pushes (0.119 failures/push) were associated with this bug yesterday.  

Repository breakdown:
* mozilla-inbound: 7
* autoland: 6
* mozilla-central: 2
* graphics: 1

Platform breakdown:
* linux32: 9
* linux64: 5
* osx-10-10: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-02-01&endday=2017-02-01&tree=all
(In reply to Geoff Brown [:gbrown] from comment #10)
> I don't see any recent changes that look related to this frequent
> intermittent failure. The AreDialogsEnabled() assertion has been in place
> for a long time and doesn't seem to be hit during other tests. 
> 
> Andrew - Would it be okay to allow assertions in this test (mark with
> something like expectAssertions(0,10)) ?

How much is that better than just disabling this test? If we ignore that this test fails we should just disable it so it's more obvious (which might be the right call I don't know how much we care about the browser element in general).

I don't know anything about this area but the concerning error is:
[task 2017-02-01T06:27:49.131682Z] 06:27:49     INFO - JavaScript error: resource://gre/components/BrowserElementParent.js, line 227: NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXPCComponents_Utils.isDeadWrapper]
Which means that the browser element is being used before it is initialized. It's not obvious to me where is it used from that can trigger this error.
Flags: needinfo?(gkrizsanits)
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #14)
> (In reply to Geoff Brown [:gbrown] from comment #10)
> > Andrew - Would it be okay to allow assertions in this test (mark with
> > something like expectAssertions(0,10)) ?
> 
> How much is that better than just disabling this test? If we ignore that
> this test fails we should just disable it so it's more obvious (which might
> be the right call I don't know how much we care about the browser element in
> general).

Either approach is fine with me. expectAssertions() is a good solution when the test is considered valuable but the assertion is not understood, or not important in the test context.

Comment 16

2 years ago
32 failures in 149 pushes (0.215 failures/push) were associated with this bug yesterday.  

Repository breakdown:
* autoland: 20
* mozilla-inbound: 7
* mozilla-central: 3
* graphics: 2

Platform breakdown:
* linux32: 19
* linux64: 9
* osx-10-10: 4

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

Comment 17

2 years ago
28 failures in 140 pushes (0.2 failures/push) were associated with this bug yesterday.  

Repository breakdown:
* autoland: 17
* mozilla-inbound: 9
* mozilla-central: 2

Platform breakdown:
* linux32: 17
* osx-10-10: 7
* linux64: 4

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-02-03&endday=2017-02-03&tree=all

Comment 18

2 years ago
136 failures in 733 pushes (0.186 failures/push) were associated with this bug in the last 7 days. 

This is the #2 most frequent failure this week. 

** This failure happened more than 50 times this week! Resolving this bug is a high priority. **

Repository breakdown:
* autoland: 68
* mozilla-inbound: 50
* mozilla-central: 10
* graphics: 6
* try: 2

Platform breakdown:
* linux32: 69
* linux64: 36
* osx-10-10: 31

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-01-30&endday=2017-02-05&tree=all

Comment 19

2 years ago
25 failures in 117 pushes (0.214 failures/push) were associated with this bug yesterday.  

Repository breakdown:
* autoland: 13
* mozilla-inbound: 8
* mozilla-central: 2
* try: 1
* graphics: 1

Platform breakdown:
* osx-10-10: 10
* linux32: 10
* linux64: 5

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-02-06&endday=2017-02-06&tree=all
(In reply to Geoff Brown [:gbrown] from comment #15)
> Either approach is fine with me. expectAssertions() is a good solution when
> the test is considered valuable but the assertion is not understood, or not
> important in the test context.

I question the value of this test with these assertions, but either version
works for me too.
OK, I'll skip it.

Comment 22

2 years ago
Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8cf10b012ee2
Skip test_browserElement_inproc_AudioPlayback.html for frequent failures; r=me,test-only

Comment 23

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/8cf10b012ee2
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
status-firefox54: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Sorry, should have marked leave-open.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [test disabled]
395ms
01-23 09:32:26.595   788   808 E GeckoConsole: [JavaScript Error: "too much recursion" {file: "resource://gre/modules/BrowserElementPromptService.jsm" line: 563}]
01-23 09:32:26.675   788   808 E GeckoConsole: [JavaScript Error: "NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "too much recursion" {file: "resource://gre/modules/BrowserElementPromptService.jsm" line: 563}]'[JavaScript Error: "too much recursion" {file: "resource://gre/modules/BrowserElementPromptService.jsm" line: 563}]' when calling method: [nsIPromptFactory::getPrompt]" {file: "chrome://mochitests/content/chrome/dom/browser-element/mochitest/file_browserElement_AudioChannel_nested.html" line: 6}]

This seems to be the origin of this bug.
Flags: needinfo?(amarchesini)
(In reply to Andrea Marchesini [:baku] from comment #25)
> 395ms
> 01-23 09:32:26.595   788   808 E GeckoConsole: [JavaScript Error: "too much
> recursion" {file: "resource://gre/modules/BrowserElementPromptService.jsm"
> line: 563}]
> 01-23 09:32:26.675   788   808 E GeckoConsole: [JavaScript Error:
> "NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "too much
> recursion" {file: "resource://gre/modules/BrowserElementPromptService.jsm"
> line: 563}]'[JavaScript Error: "too much recursion" {file:
> "resource://gre/modules/BrowserElementPromptService.jsm" line: 563}]' when
> calling method: [nsIPromptFactory::getPrompt]" {file:
> "chrome://mochitests/content/chrome/dom/browser-element/mochitest/
> file_browserElement_AudioChannel_nested.html" line: 6}]
> 
> This seems to be the origin of this bug.

I don't see that in most of the failure logs.
Duplicate of this bug: 1337593
Created attachment 8836241 [details] [diff] [review]
skip inproc_AudioChannel too

As soon as I skipped test_browserElement_inproc_AudioPlayback.html, we started getting the same type of failures in bug 1337593, in test_browserElement_inproc_BackForward.html. 

In try pushes, I found that if test_browserElement_inproc_BackForward.html was skipped, then the next test started failing.

By trial and error, I found all's well if both test_browserElement_inproc_AudioPlayback.html and test_browserElement_inproc_AudioChannel.html are skipped. (Assertions cause failed tests if only one or the other is skipped.)

https://treeherder.mozilla.org/#/jobs?repo=try&revision=cf90e037ab63c0e3df9dc845d831bc29fb75d71f
Attachment #8836241 - Flags: review?(gkrizsanits)
Summary: Intermittent dom/browser-element/mochitest/test_browserElement_inproc_AudioPlayback.html | Assertion count 6 is greater than expected range 0-0 assertions. → Intermittent dom/browser-element/mochitest/test_browserElement_inproc_AudioPlayback.html, test_browserElement_inproc_BackForward.html | Assertion count 6 is greater than expected range 0-0 assertions.

Comment 29

2 years ago
92 failures in 836 pushes (0.11 failures/push) were associated with this bug in the last 7 days. 

This is the #19 most frequent failure this week. 

** This failure happened more than 30 times this week! Resolving this bug is a high priority. **

** Try to resolve this bug as soon as possible. If unresolved for 2 weeks, the affected test(s) may be disabled. **

Repository breakdown:
* autoland: 40
* mozilla-inbound: 33
* mozilla-central: 12
* try: 4
* graphics: 3

Platform breakdown:
* linux32: 38
* osx-10-10: 29
* linux64: 25

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-02-06&endday=2017-02-12&tree=all
Attachment #8836241 - Flags: review?(gkrizsanits) → review+
Comment on attachment 8836241 [details] [diff] [review]
skip inproc_AudioChannel too

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

This code soon will be all removed anyway, thanks for the patch!

Comment 31

a year ago
Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/46f095237243
Skip test_browserElement_inproc_AudioChannel, for frequent assertions; r=gabor
Keywords: leave-open
61 failures in 833 pushes (0.073 failures/push) were associated with this bug in the last 7 days. 

This is the #37 most frequent failure this week. 

** This failure happened more than 30 times this week! Resolving this bug is a high priority. **

** Try to resolve this bug as soon as possible. If unresolved for 2 weeks, the affected test(s) may be disabled. **

Repository breakdown:
* autoland: 23
* mozilla-inbound: 21
* mozilla-central: 9
* graphics: 6
* try: 2

Platform breakdown:
* osx-10-10: 49
* linux64: 7
* linux32: 5

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-02-13&endday=2017-02-19&tree=all
*Still* failing....
Flags: needinfo?(gbrown)
Keywords: leave-open
It looks like we also need to skip test_browserElement_inproc_AudioChannel_nested.html: https://treeherder.mozilla.org/#/jobs?repo=try&revision=837ceaa9603cc1e26468a87ad62faa01d2174474
Flags: needinfo?(gbrown)
Keywords: leave-open

Comment 36

a year ago
Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9b7942f48f01
Skip test_browserElement_inproc_AudioChannel_nested.html for assertions; r=me,test-only
19 failures in 182 pushes (0.104 failures/push) were associated with this bug yesterday.  
Repository breakdown:
* autoland: 8
* mozilla-inbound: 7
* graphics: 2
* try: 1
* mozilla-central: 1

Platform breakdown:
* osx-10-10: 19

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-02-24&endday=2017-02-24&tree=all
Whiteboard: [test disabled] → [test-disabled][stockwell disabled]
46 failures in 812 pushes (0.057 failures/push) were associated with this bug in the last 7 days. 

This is the #31 most frequent failure this week. 

** This failure happened more than 30 times this week! Resolving this bug is a high priority. **

** Try to resolve this bug as soon as possible. If unresolved for 2 weeks, the affected test(s) may be disabled. **

Repository breakdown:
* autoland: 21
* mozilla-inbound: 14
* graphics: 6
* mozilla-central: 3
* try: 2

Platform breakdown:
* osx-10-10: 42
* linux32: 3
* linux64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332862&startday=2017-02-20&endday=2017-02-26&tree=all
Priority: -- → P5
:overholt- these tests have been disabled for 5+ months, should we leave this bug open?
Flags: needinfo?(overholt)
(In reply to Joel Maher ( :jmaher) (UTC-8) from comment #40)
> :overholt- these tests have been disabled for 5+ months, should we leave
> this bug open?

I'll leave that decision up to baku.
Flags: needinfo?(overholt) → needinfo?(amarchesini)
Let's ask alwu. He is taking care of audio playback in these days.
If these tests are not useful, we can remove them.
Flags: needinfo?(amarchesini) → needinfo?(alwu)
(Assignee)

Comment 43

a year ago
Yes, this test is not useful anymore, we should remove it.
Assignee: nobody → alwu
Flags: needinfo?(alwu)
Comment hidden (mozreview-request)

Comment 46

a year ago
mozreview-review
Comment on attachment 8887346 [details]
Bug 1332862 - remove useless test.

https://reviewboard.mozilla.org/r/158172/#review163514
Attachment #8887346 - Flags: review?(amarchesini) → review+

Comment 49

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/0684def62744

If we're removing the test, why is the bug being kept open?
(Assignee)

Updated

a year ago
Status: REOPENED → RESOLVED
Last Resolved: 2 years agoa year ago
Keywords: leave-open
Resolution: --- → FIXED
Whiteboard: [test-disabled][stockwell disabled] → [stockwell fixed:obsolete]
status-firefox54: fixed → ---
status-firefox56: --- → fixed
Target Milestone: mozilla54 → mozilla56
You need to log in before you can comment on or make changes to this bug.