Intermittent netwerk/test/browser/browser_child_resource.js | uncaught exception - Error: Assertion failure at assert@chrome://browser/content/tabbrowser.xml:4227:25

NEW
Assigned to

Status

()

P3
normal
a year ago
a year ago

People

(Reporter: intermittent-bug-filer, Assigned: mconley)

Tracking

({intermittent-failure, leave-open})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [stockwell disabled])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

a year ago
treeherder
Filed by: philringnalda [at] gmail.com

https://treeherder.mozilla.org/logviewer.html#?job_id=105070023&repo=try

https://archive.mozilla.org/pub/firefox/try-builds/philringnalda@gmail.com-4ad947a83cfaf37b67206eb782b5cc2c0da819a6/try-win64-debug/try_win8_64-debug_test-mochitest-e10s-browser-chrome-6-bm111-tests1-windows-build102.txt.gz

Be interesting to find out whether this is only intermittent on Gecko 55 after it hits mozilla-beta (I've seen it several times while doing simulations of 55-as-beta on try), or is intermittently happening on the trunk and nobody can be bothered to file it.
5 failures in 864 pushes (0.006 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* try: 5

Platform breakdown:
* windows7-32-vm: 3
* windows8-64: 1
* osx-10-10: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-06-05&endday=2017-06-11&tree=all
Indeed, 11 failures on beta already.
The crash stack.

>20:24:14     INFO - GECKO(1232) | [Parent 1232] ###!!! ASSERTION: QueryInterface needed: 'query_result.get() == mRawPtr', file c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\src\obj-firefox\dist\include\nsCOMPtr.h, line 414
>20:24:15     INFO - GECKO(1232) | #01: nsDocShell::InternalLoad(nsIURI *,nsIURI *,bool,nsIURI *,unsigned int,nsIPrincipal *,nsIPrincipal *,unsigned int,nsAString const &,char const *,nsAString const &,nsIInputStream *,nsIInputStream *,unsigned int,nsISHEntry *,bool,nsAString const &,nsIDocShell *,nsIURI *,bool,nsIDocShell * *,nsIRequest * *) [docshell/base/nsDocShell.cpp:10752]
>20:24:15     INFO - 
>20:24:15     INFO - GECKO(1232) | #02: nsDocShell::OnLinkClickSync(nsIContent *,nsIURI *,char16_t const *,nsAString const &,nsIInputStream *,nsIInputStream *,bool,nsIDocShell * *,nsIRequest * *,nsIPrincipal *) [docshell/base/nsDocShell.cpp:14212]
>20:24:15     INFO - 
>20:24:15     INFO - GECKO(1232) | #03: OnLinkClickEvent::Run() [docshell/base/nsDocShell.cpp:13972]
>20:24:15     INFO - 
>20:24:15     INFO - GECKO(1232) | #04: nsThread::ProcessNextEvent(bool,bool *) [xpcom/threads/nsThread.cpp:1369]
>20:24:15     INFO - 
>20:24:15     INFO - GECKO(1232) | #05: NS_ProcessNextEvent(nsIThread *,bool) [xpcom/threads/nsThreadUtils.cpp:472]
>20:24:15     INFO - 
>20:24:15     INFO - GECKO(1232) | #06: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate *) [ipc/glue/MessagePump.cpp:96]
>20:24:15     INFO - 
>20:24:15     INFO - GECKO(1232) | #07: MessageLoop::RunInternal() [ipc/chromium/src/base/message_loop.cc:238]
>20:24:15     INFO - 
>20:24:15     INFO - GECKO(1232) | #08: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:232]
>20:24:15     INFO - 
>20:24:15     INFO - GECKO(1232) | #09: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:212]
>20:24:15     INFO - 
>20:24:15     INFO - GECKO(1232) | #10: nsBaseAppShell::Run() [widget/nsBaseAppShell.cpp:158]
>20:24:15     INFO - 
>20:24:15     INFO - GECKO(1232) | #11: nsAppShell::Run() [widget/windows/nsAppShell.cpp:271]
The crash complains about the conversion from nsIRequest to nsCOMPtr<nsIRequest> via getter_AddRefs<>.
https://searchfox.org/mozilla-central/rev/61054508641ee76f9c49bcf7303ef3cfb6b410d2/docshell/base/nsDocShell.cpp#10747
https://searchfox.org/mozilla-central/rev/61054508641ee76f9c49bcf7303ef3cfb6b410d2/xpcom/base/nsCOMPtr.h#414

Maybe replacing the NS_ADDREF statement with

nsCOMPtr<nsIRequest> req = do_QueryInterface(channel);
req.forget(aRequest);

in nsDocShell::DoURILoad can fix it. However it would be good to know which channel implementation makes the static type casting failed before we cover it up.
https://searchfox.org/mozilla-central/rev/61054508641ee76f9c49bcf7303ef3cfb6b410d2/docshell/base/nsDocShell.cpp#11131
Hmm...this test case is about res:// protocol, however there is no recent modification on nsResProtocolHandler.
17 failures in 131 pushes (0.13 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* mozilla-beta: 11
* try: 6

Platform breakdown:
* osx-10-10: 8
* windows7-32-vm: 6
* windows8-64: 3

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-06-15&endday=2017-06-15&tree=all
58 failures in 814 pushes (0.071 failures/push) were associated with this bug in the last 7 days. 

This is the #34 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:
* mozilla-beta: 52
* try: 6

Platform breakdown:
* windows7-32-vm: 24
* osx-10-10: 21
* windows8-64: 13

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-06-12&endday=2017-06-18&tree=all
47 failures in 892 pushes (0.053 failures/push) were associated with this bug in the last 7 days. 

This is the #42 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:
* mozilla-beta: 45
* try: 2

Platform breakdown:
* windows8-64: 18
* windows7-32-vm: 16
* osx-10-10: 13

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-06-19&endday=2017-06-25&tree=all
Do you want to take a look?
Flags: needinfo?(schien)
Comment hidden (mozreview-request)
Patch is created according to my previous analysis on comment #4.
Flags: needinfo?(schien)

Comment 12

a year ago
mozreview-review
Comment on attachment 8882046 [details]
Bug 1370783 - use QI instead of static cast from nsIChannel to nsIRequest.

https://reviewboard.mozilla.org/r/153054/#review158414

This really looks like just hiding some actual bug elsewhere. How do we get wrong channel pointer there? nsIChannel after all extends nsIRequest.
Attachment #8882046 - Flags: review?(bugs) → review-
Whiteboard: [necko-next]
35 failures in 718 pushes (0.049 failures/push) were associated with this bug in the last 7 days. 

This is the #49 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:
* mozilla-beta: 35

Platform breakdown:
* windows8-64: 15
* windows7-32-vm: 10
* osx-10-10: 10

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-06-26&endday=2017-07-02&tree=all
After further debugging, the 'QueryInterface needed' assertion is generated by browser_about_cache.js but not browser_child_resource.js. Bug 1379095 is filed for the corresponding fix. Unfortunately this intermittent failure still exists even if Bug 1379095 is fixed.
39 failures in 656 pushes (0.059 failures/push) were associated with this bug in the last 7 days. 

This is the #40 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:
* mozilla-beta: 39

Platform breakdown:
* windows8-64: 17
* windows7-32-vm: 13
* osx-10-10: 9

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-07-03&endday=2017-07-09&tree=all
This test case failure is complaining about an unexpected assertion in tabbrowser.xml
>09:09:48     INFO -  GECKO(1708) | assert@chrome://browser/content/tabbrowser.xml:4273:46
>09:09:48     INFO -  GECKO(1708) | finish@chrome://browser/content/tabbrowser.xml:4130:15
>09:09:48     INFO -  GECKO(1708) | postActions@chrome://browser/content/tabbrowser.xml:4394:17
>09:09:48     INFO -  GECKO(1708) | onUnloadTimeout@chrome://browser/content/tabbrowser.xml:4432:15
>09:09:48     INFO -  GECKO(1708) | requestTab/this.unloadTimer<@chrome://browser/content/tabbrowser.xml:4626:54

Tried to enable log in tabbrowser.xml.

In success case, the tab is consider as non-blank while unload timer timeout.
https://treeherder.mozilla.org/logviewer.html#?job_id=112953460&repo=try&lineNumber=43608

However in failure case, the tab is consider as blank at that time.
https://treeherder.mozilla.org/logviewer.html#?job_id=112953462&repo=try&lineNumber=43761

This is less likely to be a networking issue but a UI issue.


[full try push]
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e38b6142b94bc332324c7bc3c44494b075f675d9
Assignee: nobody → schien
46 failures in 720 pushes (0.064 failures/push) were associated with this bug in the last 7 days. 

This is the #23 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:
* mozilla-beta: 46

Platform breakdown:
* windows8-64: 20
* windows7-32-vm: 14
* osx-10-10: 12

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-07-10&endday=2017-07-16&tree=all
20 failures in 190 pushes (0.105 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* mozilla-beta: 19
* try: 1

Platform breakdown:
* windows7-32-vm: 10
* windows8-64: 6
* osx-10-10: 4

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-07-20&endday=2017-07-20&tree=all
62 failures in 822 pushes (0.075 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:
* mozilla-beta: 61
* try: 1

Platform breakdown:
* windows7-32-vm: 30
* windows8-64: 19
* osx-10-10: 13

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

** 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:
* mozilla-beta: 47
* try: 2

Platform breakdown:
* windows8-64: 19
* windows7-32-vm: 19
* osx-10-10: 11

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-07-24&endday=2017-07-30&tree=all
Just as failtastic on Beta56 in case anybody was wondering. Really hope we can make some progress on this soon.
34 failures in 888 pushes (0.038 failures/push) were associated with this bug in the last 7 days.   

** 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:
* mozilla-beta: 20
* mozilla-release: 14

Platform breakdown:
* windows8-64: 10
* windows7-32-vm: 10
* osx-10-10: 10
* windows7-32: 4

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-07-31&endday=2017-08-06&tree=all
18 failures in 182 pushes (0.099 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* mozilla-beta: 11
* mozilla-release: 7

Platform breakdown:
* osx-10-10: 7
* windows8-64: 5
* windows7-32: 4
* windows7-32-vm: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-08-08&endday=2017-08-08&tree=all
25 failures in 156 pushes (0.16 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* mozilla-beta: 13
* mozilla-release: 12

Platform breakdown:
* windows8-64: 8
* osx-10-10: 8
* windows7-32-vm: 5
* windows7-32: 4

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-08-09&endday=2017-08-09&tree=all
Based on my investigation on comment #16, need more information from someone familiar with tabbrowser.xml.
Unassigned myself and dispatch this bug to Firefox:Tabbed Browser component.
Assignee: schien → nobody
Component: Networking → Tabbed Browser
Product: Core → Firefox
Whiteboard: [necko-next]

Comment 26

a year ago
(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #25)
> Based on my investigation on comment #16, need more information from someone
> familiar with tabbrowser.xml.
> Unassigned myself and dispatch this bug to Firefox:Tabbed Browser component.

Just moving the bug doesn't do much. Please find an owner if you can't own this, and/or clarify what is actually needed here - why is this a tabbrowser issue? What information do you need? What does comment 16 even mean?

(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #16)
> This test case failure is complaining about an unexpected assertion in
> tabbrowser.xml
> >09:09:48     INFO -  GECKO(1708) | assert@chrome://browser/content/tabbrowser.xml:4273:46
> >09:09:48     INFO -  GECKO(1708) | finish@chrome://browser/content/tabbrowser.xml:4130:15
> >09:09:48     INFO -  GECKO(1708) | postActions@chrome://browser/content/tabbrowser.xml:4394:17
> >09:09:48     INFO -  GECKO(1708) | onUnloadTimeout@chrome://browser/content/tabbrowser.xml:4432:15
> >09:09:48     INFO -  GECKO(1708) | requestTab/this.unloadTimer<@chrome://browser/content/tabbrowser.xml:4626:54
> 
> Tried to enable log in tabbrowser.xml.
> 
> In success case, the tab is consider as non-blank while unload timer timeout.
> https://treeherder.mozilla.org/logviewer.
> html#?job_id=112953460&repo=try&lineNumber=43608
> 
> However in failure case, the tab is consider as blank at that time.
> https://treeherder.mozilla.org/logviewer.
> html#?job_id=112953462&repo=try&lineNumber=43761
> 
> This is less likely to be a networking issue but a UI issue.
> 
> 
> [full try push]
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=e38b6142b94bc332324c7bc3c44494b075f675d9

What is the "unload timer" ? What is the test trying to test and what does that have to do with tabbrowser, if it's a netwerk/ test?
Flags: needinfo?(schien)
See Also: → bug 1372308
See Also: → bug 1378628
See Also: → bug 1381204
browser_child_resource.js uses "await BrowserTestUtils.crashBrowser(browser); browser.reload();" to ensure resource URL loaded on a fresh content process. (@mossop can help clarify the purpose since he is the author of this test case).

Test case is failed to complete due to an assertion in tabbrowser.xml.
>00:03:11     INFO -  finish@chrome://browser/content/tabbrowser.xml:4195:15
>00:03:11     INFO -  postActions@chrome://browser/content/tabbrowser.xml:4470:17
>00:03:11     INFO -  handleEvent@chrome://browser/content/tabbrowser.xml:4735:15
>00:03:11     INFO -  updateBrowserRemoteness@chrome://browser/content/tabbrowser.xml:1958:13
>00:03:11     INFO -  onxbloop-browser-crashed@chrome://browser/content/tabbrowser.xml:5791:13

https://dxr.mozilla.org/mozilla-beta/rev/423e59c17f37225371b4d9fa8c207eb1e0a752b5/browser/base/content/tabbrowser.xml#4195
> this.assert(!this.loadTimer);

I'd like someone familiar with tabbrowser.xml to check why loadTimer is not null when |BrowserTestUtils.crashBrowser| is invoked.

@gijs can you help on this?
Flags: needinfo?(schien) → needinfo?(gijskruitbosch+bugs)

Comment 28

a year ago
(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #27)
> browser_child_resource.js uses "await
> BrowserTestUtils.crashBrowser(browser); browser.reload();" to ensure
> resource URL loaded on a fresh content process. (@mossop can help clarify
> the purpose since he is the author of this test case).
> 
> Test case is failed to complete due to an assertion in tabbrowser.xml.
> >00:03:11     INFO -  finish@chrome://browser/content/tabbrowser.xml:4195:15
> >00:03:11     INFO -  postActions@chrome://browser/content/tabbrowser.xml:4470:17
> >00:03:11     INFO -  handleEvent@chrome://browser/content/tabbrowser.xml:4735:15
> >00:03:11     INFO -  updateBrowserRemoteness@chrome://browser/content/tabbrowser.xml:1958:13
> >00:03:11     INFO -  onxbloop-browser-crashed@chrome://browser/content/tabbrowser.xml:5791:13
> 
> https://dxr.mozilla.org/mozilla-beta/rev/
> 423e59c17f37225371b4d9fa8c207eb1e0a752b5/browser/base/content/tabbrowser.
> xml#4195
> > this.assert(!this.loadTimer);
> 
> I'd like someone familiar with tabbrowser.xml to check why loadTimer is not
> null when |BrowserTestUtils.crashBrowser| is invoked.
> 
> @gijs can you help on this?

I'm not sure off-hand. Maybe Dave knows or knows someone who knows.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(dtownsend)
(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #27)
> browser_child_resource.js uses "await
> BrowserTestUtils.crashBrowser(browser); browser.reload();" to ensure
> resource URL loaded on a fresh content process. (@mossop can help clarify
> the purpose since he is the author of this test case).

The point is to verify that new content processes have the resource mappings.

> Test case is failed to complete due to an assertion in tabbrowser.xml.
> >00:03:11     INFO -  finish@chrome://browser/content/tabbrowser.xml:4195:15
> >00:03:11     INFO -  postActions@chrome://browser/content/tabbrowser.xml:4470:17
> >00:03:11     INFO -  handleEvent@chrome://browser/content/tabbrowser.xml:4735:15
> >00:03:11     INFO -  updateBrowserRemoteness@chrome://browser/content/tabbrowser.xml:1958:13
> >00:03:11     INFO -  onxbloop-browser-crashed@chrome://browser/content/tabbrowser.xml:5791:13
> 
> https://dxr.mozilla.org/mozilla-beta/rev/
> 423e59c17f37225371b4d9fa8c207eb1e0a752b5/browser/base/content/tabbrowser.
> xml#4195
> > this.assert(!this.loadTimer);
> 
> I'd like someone familiar with tabbrowser.xml to check why loadTimer is not
> null when |BrowserTestUtils.crashBrowser| is invoked.
> 
> @gijs can you help on this?

I'm going to defer to mconley, I think he did most of the async tab switching code.
Flags: needinfo?(dtownsend) → needinfo?(mconley)
76 failures in 901 pushes (0.084 failures/push) were associated with this bug in the last 7 days. 

This is the #11 most frequent failure this week. 

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

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

Repository breakdown:
* mozilla-beta: 50
* mozilla-release: 26

Platform breakdown:
* osx-10-10: 26
* windows8-64: 20
* windows7-32: 19
* windows7-32-vm: 11

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-08-07&endday=2017-08-13&tree=all
29 failures in 149 pushes (0.195 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* mozilla-beta: 17
* mozilla-release: 12

Platform breakdown:
* osx-10-10: 9
* windows7-32: 8
* windows8-64: 6
* windows7-32-vm: 6

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-08-14&endday=2017-08-14&tree=all
22 failures in 194 pushes (0.113 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* mozilla-beta: 15
* mozilla-release: 4
* try: 3

Platform breakdown:
* osx-10-10: 8
* windows7-32: 6
* windows8-64: 5
* windows7-32-vm: 2
* macosx64-stylo: 1

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

This is the #16 most frequent failure this week. 

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

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

Repository breakdown:
* mozilla-beta: 53
* mozilla-release: 22
* try: 8

Platform breakdown:
* osx-10-10: 29
* windows7-32: 24
* windows8-64: 17
* windows7-32-vm: 12
* macosx64-stylo: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-08-14&endday=2017-08-20&tree=all
(Assignee)

Comment 34

a year ago
Looking.
Assignee: nobody → mconley
Flags: needinfo?(mconley)
Comment hidden (mozreview-request)
(Assignee)

Comment 37

a year ago
It _looks_ like this fixes the intermittent, but it also introduces a mostly permanent failure in toolkit/content/tests/browser/browser_sound_indicator_silent_video.js of all places.

Still poking.
18 failures in 173 pushes (0.104 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* try: 12
* mozilla-beta: 6

Platform breakdown:
* windows8-64: 7
* windows7-32: 4
* windows7-32-stylo: 3
* osx-10-10: 2
* windows10-64-stylo: 1
* windows10-64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-08-23&endday=2017-08-23&tree=all
16 failures in 196 pushes (0.082 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* mozilla-beta: 13
* try: 3

Platform breakdown:
* windows7-32: 7
* windows8-64: 6
* osx-10-10: 3

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-08-25&endday=2017-08-25&tree=all
71 failures in 908 pushes (0.078 failures/push) were associated with this bug in the last 7 days. 

This is the #24 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:
* mozilla-beta: 52
* try: 15
* mozilla-release: 4

Platform breakdown:
* windows8-64: 24
* windows7-32: 22
* osx-10-10: 20
* windows7-32-stylo: 3
* windows10-64-stylo: 1
* windows10-64: 1

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

This is the #34 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:
* mozilla-beta: 40
* try: 27

Platform breakdown:
* windows8-64: 21
* windows7-32: 17
* osx-10-10: 15
* windows7-32-stylo: 8
* macosx64-stylo: 4
* windows10-64: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-08-28&endday=2017-09-03&tree=all
Hey Mike, I don't suppose you've had any time to take a fresh look at this one? Still the #1 orange on Beta56 and on the 57-as-Beta simulations.
Flags: needinfo?(mconley)
16 failures in 173 pushes (0.092 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* mozilla-beta: 9
* try: 7

Platform breakdown:
* windows7-32: 4
* osx-10-10: 4
* windows8-64: 3
* macosx64-stylo-disabled: 3
* windows7-32-stylo-disabled: 1
* windows10-64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-09-08&endday=2017-09-08&tree=all
63 failures in 924 pushes (0.068 failures/push) were associated with this bug in the last 7 days. 

This is the #36 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:
* mozilla-beta: 32
* try: 31

Platform breakdown:
* windows8-64: 17
* osx-10-10: 16
* windows7-32: 15
* macosx64-stylo-disabled: 7
* windows7-32-stylo-disabled: 3
* windows7-32-stylo: 3
* windows10-64-stylo-disabled: 1
* windows10-64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-09-04&endday=2017-09-10&tree=all
26 failures in 247 pushes (0.105 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* mozilla-beta: 16
* try: 10

Platform breakdown:
* windows8-64: 8
* osx-10-10: 8
* windows7-32: 7
* windows7-32-stylo-disabled: 2
* macosx64-stylo-disabled: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-09-13&endday=2017-09-13&tree=all
(Assignee)

Updated

a year ago
Attachment #8899921 - Flags: review?(gijskruitbosch+bugs)

Comment 47

a year ago
mozreview-review
Comment on attachment 8899921 [details]
Bug 1370783 - Account for tabs that have just crashed when updating state in preActions of async tab switcher.

https://reviewboard.mozilla.org/r/171252/#review185054

I mean, this change makes sense, so tentative r+ .

Did you figure out the permafailure in that video test? Your last trypush doesn't seem to have the win8 tests it was failing on.

::: browser/base/content/tabbrowser.xml:4402
(Diff revision 1)
> +                 (this.loadingTab.linkedBrowser.isRemoteBrowser &&
> +                  !this.loadingTab.linkedBrowser.frameLoader.tabParent));

As discussed on IRC, we probably want to do the same in the loop at the top of this method.
Attachment #8899921 - Flags: review?(gijskruitbosch+bugs) → review+
36 failures in 191 pushes (0.188 failures/push) were associated with this bug yesterday.    

** This test has failed more than 200 times in the last 30 days. It should be disabled until it can be fixed. ** 

Repository breakdown:
* try: 26
* mozilla-beta: 7
* mozilla-release: 3

Platform breakdown:
* windows8-64: 20
* windows7-32: 9
* windows10-64: 3
* osx-10-10: 3
* windows7-32-stylo-disabled: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-09-14&endday=2017-09-14&tree=all
Whiteboard: [stockwell disable-recommended]
(Assignee)

Comment 49

a year ago
mozreview-review-reply
Comment on attachment 8899921 [details]
Bug 1370783 - Account for tabs that have just crashed when updating state in preActions of async tab switcher.

https://reviewboard.mozilla.org/r/171252/#review185054

Thanks for the heads up - I used the same try syntax, but I guess the defaults changed.

I did a run on Win 8 64 debug bc1, and it ran browser_sound_indicator_silent_video.js and seems to pass now.

¯\_(ツ)_/¯

> As discussed on IRC, we probably want to do the same in the loop at the top of this method.

Thanks, will do and then land.
16 failures in 149 pushes (0.107 failures/push) were associated with this bug yesterday.    

Repository breakdown:
* mozilla-beta: 8
* mozilla-release: 6
* try: 2

Platform breakdown:
* windows8-64: 6
* osx-10-10: 6
* windows7-32: 4

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-09-15&endday=2017-09-15&tree=all
17 failures in 75 pushes (0.227 failures/push) were associated with this bug yesterday.    

Repository breakdown:
* try: 9
* mozilla-release: 5
* mozilla-beta: 3

Platform breakdown:
* osx-10-10: 6
* windows10-64-stylo-disabled: 3
* windows8-64: 2
* windows7-32: 2
* macosx64-stylo-disabled: 2
* windows7-32-stylo-disabled: 1
* windows10-64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-09-16&endday=2017-09-16&tree=all
121 failures in 1032 pushes (0.117 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 75 times this week! Resolving this bug is a very high priority. **

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

Repository breakdown:
* mozilla-beta: 55
* try: 50
* mozilla-release: 16

Platform breakdown:
* windows8-64: 44
* osx-10-10: 35
* windows7-32: 30
* windows7-32-stylo-disabled: 4
* windows10-64-stylo-disabled: 3
* windows10-64: 3
* macosx64-stylo-disabled: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-09-11&endday=2017-09-17&tree=all
will this land today? I was going to disable this test and then saw the comment from Friday about a fix!
(Assignee)

Comment 54

a year ago
mozreview-review-reply
Comment on attachment 8899921 [details]
Bug 1370783 - Account for tabs that have just crashed when updating state in preActions of async tab switcher.

https://reviewboard.mozilla.org/r/171252/#review185054

> Thanks, will do and then land.

So I did this locally, and when manually testing, noticed that there seemed to be cases where switching to crashed tabs would result in a perma-spinner and we'd never show about:tabcrashed. We're late enough in the cycle, and I'm sufficiently spooked enough, that I don't think I'm going to have this change be part of the patch. I'll file a new bug and we can investigate in the next cycle.
Comment hidden (mozreview-request)
(Assignee)

Comment 56

a year ago
I'm sufficiently paranoid about this change so late in the cycle that I'm going to ni? billm just to make sure my thinking here is sound.
Flags: needinfo?(mconley) → needinfo?(wmccloskey)
(Assignee)

Comment 57

a year ago
Er, to be clear, my needinfo? is essentially a feedback? flag.

Comment 58

a year ago
Pushed by jmaher@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/14e8c355a039
Disable netwerk/test/browser/browser_child_resource.js on debug for frequent failures. r=me, a=test-only
disabled this test to reduce the impact on the trees- please remember to enable this when testing a fix on try and landing!
Keywords: leave-open
Whiteboard: [stockwell disable-recommended] → [stockwell disabled]
Could you explain this change more, Mike? From the exception stack, we went through onRemotenessChange (presumably due to the crash). Is the problem that isRemoteBrowser is still true? I don't see why that would be since updateBrowserRemoteness should have already set it to false before it fires the TabRemotenessChange event.

If isRemoteBrowser is false, then I would expect us to take this path:
http://searchfox.org/mozilla-central/rev/1c13d5cf85f904afb8976c02a80daa252b893fca/browser/base/content/tabbrowser.xml#4829
And I would expect loadTimer and loadingTab to be nulled out there.
Flags: needinfo?(wmccloskey) → needinfo?(mconley)
(Assignee)

Comment 61

a year ago
(In reply to Bill McCloskey (:billm) from comment #60)
> I don't see why that would be since
> updateBrowserRemoteness should have already set it to false before it fires
> the TabRemotenessChange event.
> 

You're right. I forgot we'd gotten through the updateBrowserRemoteness path. My change doesn't make much sense now - thanks for the second set of eyes!

For some reason I thought we might have gotten into a case where a remote browser had crashed, but we hadn't flipped its remoteness, so it was in that "just crashed" busted state.

So I think we're back at square one here.
Flags: needinfo?(mconley)
37 failures in 943 pushes (0.039 failures/push) were associated with this bug in the last 7 days. 

This is the #46 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:
* mozilla-release: 30
* mozilla-beta: 4
* try: 3

Platform breakdown:
* osx-10-10: 14
* windows7-32: 12
* windows8-64: 9
* windows7-32-stylo-disabled: 1
* macosx64-stylo-disabled: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-09-18&endday=2017-09-24&tree=all
See Also: bug 1381204
17 failures in 885 pushes (0.019 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* mozilla-release: 17

Platform breakdown:
* windows8-64: 9
* windows7-32: 4
* osx-10-10: 4

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-09-25&endday=2017-10-01&tree=all
4 failures in 824 pushes (0.005 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* mozilla-release: 4

Platform breakdown:
* windows8-64: 2
* windows7-32: 1
* osx-10-10: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-10-02&endday=2017-10-08&tree=all
Priority: -- → P3
10 failures in 947 pushes (0.011 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* mozilla-release: 10

Platform breakdown:
* windows7-32: 5
* windows8-64: 3
* osx-10-10: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-10-09&endday=2017-10-15&tree=all
3 failures in 864 pushes (0.003 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* mozilla-release: 3

Platform breakdown:
* osx-10-10: 2
* windows7-32: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-10-16&endday=2017-10-22&tree=all
6 failures in 912 pushes (0.007 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* mozilla-release: 6

Platform breakdown:
* windows7-32: 3
* osx-10-10: 3

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

Repository breakdown:
* mozilla-release: 1

Platform breakdown:
* osx-10-10: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1370783&startday=2017-10-30&endday=2017-11-05&tree=all
You need to log in before you can comment on or make changes to this bug.