Closed Bug 1307347 Opened 8 years ago Closed 7 years ago

Intermittent devtools/client/webconsole/test/browser_console_history_persist.js | Test timed out -

Categories

(DevTools :: Console, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 53

People

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

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell fixed])

Attachments

(1 file)

Priority: -- → P3
as a note, I saw this while running tests by themselves (fresh profile, process with no tests before/after):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=72375369a12a65e716cdc7afa3a81200a4857dfb&filter-searchStr=dt10&selectedJob=30144802
:bgrins, can you help find someone to look at this bug?  I don't believe this is a product of the linux32-debug slow devtools.
Flags: needinfo?(bgrinstead)
This test is loading 5 tabs and opening the console in each, so I suspect it's running out of time in debug builds.  In some pushes it's only getting to the first tab [0] in others the third [1] and sometimes it's almost done when it times out [2]. Seems like a case where a longer timeout would help.

[0]: https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-inbound&job_id=65701086&lineNumber=1854
[1]: https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-release&job_id=66112439&lineNumber=1926
[2]: https://treeherder.mozilla.org/logviewer.html#?repo=autoland&job_id=66112921&lineNumber=4618
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
Flags: needinfo?(bgrinstead)
Attachment #8826312 - Flags: review+
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c00506e03983
Longer timeout for browser_console_history_persist.js.
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/c00506e03983
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53
This is still failing frequently.

e10s only, all desktop platforms.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I checked several recent failures on different platforms and they all "end" the same way now:

15:40:29     INFO - TEST-PASS | devtools/client/webconsole/test/browser_console_history_persist.js | Third tab has updated history (and purged the first result) after running a command - 
15:40:29     INFO - Buffered messages logged at 15:39:03
15:40:29     INFO - TEST-PASS | devtools/client/webconsole/test/browser_console_history_persist.js | Fourth tab has most recent history - 
15:40:29     INFO - TEST-PASS | devtools/client/webconsole/test/browser_console_history_persist.js | Clearing history for a tab works - 

I'll try to investigate further.
Flags: needinfo?(gbrown)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d4d084933e52ca68483bb882d1d4cd7c3192ea9c reproduces the failure a few times with additional logging. There was variation in which tab was loading, but all hung waiting for loadTab to complete.
Flags: needinfo?(gbrown)
:pbro, since :bgrins is out, I am looking to you to help out here, we still have a very high failure rate with this test, primarily on osx, but linux is common as well- this is an e10s only failure.
Flags: needinfo?(pbrosset)
I think a little attention to loadTab() would go a long way here. I'm sure (from comment 38) that a hang is possible in loadTab() and I've seen other webconsole tests hang in suspiciously similar ways.
(In reply to Geoff Brown [:gbrown] from comment #43)
> I think a little attention to loadTab() would go a long way here. I'm sure
> (from comment 38) that a hang is possible in loadTab() and I've seen other
> webconsole tests hang in suspiciously similar ways.
Indeed, all failure logs I looked at show that the test hands when calling loadTab again. The test doesn't always fail at the same place, but always when calling this function.
I have no idea what's going on here, and wasn't able to repro locally yet.
I know we have another openTab shared test helper somewhere that is equivalent to what loadTab does. So I'll get rid of loadTab and use this helper instead. If only for cleaning things up.
Let's see if using the shared openTab helper changes anything:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=1a6768767121ecbd72b36cec6dbb18c46c09be1a
Flags: needinfo?(pbrosset)
(In reply to Patrick Brosset <:pbro> from comment #47)
> Let's see if using the shared openTab helper changes anything:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=1a6768767121ecbd72b36cec6dbb18c46c09be1a
Scratch that. 2nd attempt: https://treeherder.mozilla.org/#/jobs?repo=try&revision=92511264ba778bd5c748ebfef1082a3f42fb4d0b&group_state=expanded
Sorry for the lack of activity here, I'm off on vacations until next week. The simple change I made seems green on try. I have retriggered a few additional runs just now.
Should we just land it?
Joel, I won't be able to land this until next week, but patch https://hg.mozilla.org/try/rev/34b40ad531ddd88a01157900ee9401609133cfbb seems to do the trick, feel free to push it!
Flags: needinfo?(jmaher)
Pushed by jmaher@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b113fa67207
Get rid of duplicated loadTab/removeTab code in webconsole tests. r=jmaher
thanks, did a r=me on that and lets get this landed!
Flags: needinfo?(jmaher)
https://hg.mozilla.org/mozilla-central/rev/1b113fa67207
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Whiteboard: [stockwell fixed]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.