Closed Bug 918507 Opened 6 years ago Closed 6 years ago

Intermittent browser_dbg_chrome-create.js | application timed out after 330 seconds with no output

Categories

(DevTools :: Debugger, defect)

x86
Windows 8
defect
Not set

Tracking

(firefox30 wontfix, firefox31 fixed, firefox32 fixed, firefox-esr24 wontfix)

RESOLVED FIXED
Firefox 32
Tracking Status
firefox30 --- wontfix
firefox31 --- fixed
firefox32 --- fixed
firefox-esr24 --- wontfix

People

(Reporter: RyanVM, Assigned: past)

References

Details

(Keywords: intermittent-failure, Whiteboard: [qa-] )

Attachments

(1 file, 1 obsolete file)

https://tbpl.mozilla.org/php/getParsedLog.php?id=28093288&tree=B2g-Inbound

WINNT 6.2 b2g-inbound opt test mochitest-browser-chrome on 2013-09-19 06:49:41 PDT for push ecae0b6f22e3
slave: t-w864-ix-097

07:04:59     INFO -  TEST-START | chrome://mochitests/content/browser/browser/devtools/debugger/test/browser_dbg_chrome-create.js
07:04:59     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/devtools/debugger/test/browser_dbg_chrome-create.js | Initializing a chrome debugger process.
07:10:29  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/debugger/test/browser_dbg_chrome-create.js | application timed out after 330 seconds with no output
07:10:29     INFO -  INFO | automation.py | Launching: C:\slave\test\build\tests\bin\screenshot.exe c:\users\cltbld~1.t-w\appdata\local\temp\mozilla-test-fail_q3gsnu
07:10:29     INFO -  SCREENSHOT: <see log>
07:27:09     INFO - mozprocess timed out
07:27:09    ERROR - timed out after 1000 seconds of no output
This is a dupe of bug 860349, it's the same file. Bug 876277 renamed it.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 860349
reopening this rather than bug 860349, since all the latest occurrences are already starred over here.
Status: RESOLVED → REOPENED
Depends on: 860349
Resolution: DUPLICATE → ---
What kind of crash is this? It doesn't look familiar to me.
It's the process being force-killed after timing out.
I added some more logging in a try push to see what is going on:
https://tbpl.mozilla.org/?tree=Try&rev=53a00002f540
Hmm, I couldn't reproduce this failure in my try push after about 100 test runs.
(In reply to Panos Astithas [:past] from comment #49)
> Hmm, I couldn't reproduce this failure in my try push after about 100 test
> runs.

FWIW, these failures seem to happen in clusters across trees when they occur. Maybe related to infra somehow? Do these tests touch the network in some way? Scheduled tasks running on the slaves?
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #150)
> FWIW, these failures seem to happen in clusters across trees when they
> occur. Maybe related to infra somehow? Do these tests touch the network in
> some way? Scheduled tasks running on the slaves?

The next line after the last log output is this:

http://dxr.mozilla.org/mozilla-central/source/browser/devtools/framework/ToolboxProcess.jsm#111

The test is spawning a separate Firefox process that it will connect to using a local TCP socket, but at that point the process hasn't started yet, we are merely trying to decide if we should create or reuse an existing profile for the new process. Do we store the profile directory in NFS or something like that? Do we run a periodic profile cleanup task that could interfere with the test?
Attached patch Add more logging (obsolete) — Splinter Review
Victor, how about just adding the logging anyway, at least until we resolve the issue? We have lots of that anyway and it's hidden behind a pref.
Attachment #8388430 - Flags: review?(vporof)
Assignee: nobody → past
Status: REOPENED → ASSIGNED
Attachment #8388430 - Flags: review?(vporof) → review+
(In reply to Panos Astithas [:past] from comment #227)

Is logging disabled by default for all debugger tests though?
Ugh, I forgot about that! Maybe we should just enable logging for debugger tests, at least temporarily. Other devtools tests have it enabled by default already.
Rob, how about enabling protocol logging by default for debugger tests, at least temporarily? I can't think of another way to understand what is happening here.
Flags: needinfo?(rcampbell)
(In reply to Panos Astithas [:past] from comment #233)
> Rob, how about enabling protocol logging by default for debugger tests, at
> least temporarily? I can't think of another way to understand what is
> happening here.

alright. I hope this doesn't crush tbpl.
Flags: needinfo?(rcampbell)
I had to back this out in https://hg.mozilla.org/integration/fx-team/rev/8d6720456275 for pushing win8debug m-bc jobs over the log length limit most of the time.

You'll need to retrigger on try or on the few builds that finished on fx-team with this patch in to catch this bug's issues.
Flags: needinfo?(past)
From the few (successful) logs I see that there is a huge number of files in the test profile, which could explain the slow execution time. I increased the timeout of the test to see if this fixes it, or makes it less common:

https://hg.mozilla.org/integration/fx-team/rev/d0863e8202df
Flags: needinfo?(past)
Whiteboard: [leave open]