Closed Bug 810185 Opened 13 years ago Closed 11 years ago

Intermittent test_profiler_actor.js | test failed, | 0 != 0, | head_dbg.js got console message: undefined

Categories

(Core :: Gecko Profiler, defect)

Product:
Core
Component:
Gecko Profiler
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: philor, Unassigned)

References

Details

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

+++ This bug was initially created as a clone of Bug #799323 +++ It's been sort of amusing starring these as the fixed bug 799323, but eventually the fun of doing that wanes. https://tbpl.mozilla.org/php/getParsedLog.php?id=16879913&tree=Mozilla-Inbound Rev4 MacOSX Lion 10.7 mozilla-inbound opt test xpcshell on 2012-11-08 18:46:08 PST for push d4a84844aa40 slave: talos-r4-lion-022 TEST-PASS | /Users/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/devtools/debugger/tests/unit/test_profiler_actor.js | [null : 114] object == object TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/devtools/debugger/tests/unit/test_profiler_actor.js | 0 != 0 - See following stack: JS frame :: /Users/cltbld/talos-slave/test/build/xpcshell/head.js :: do_throw :: line 451 JS frame :: /Users/cltbld/talos-slave/test/build/xpcshell/head.js :: _do_check_neq :: line 507 JS frame :: /Users/cltbld/talos-slave/test/build/xpcshell/head.js :: do_check_neq :: line 528 JS frame :: /Users/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/devtools/debugger/tests/unit/test_profiler_actor.js :: <TOP_LEVEL> :: line 115 JS frame :: resource://gre/modules/devtools/dbg-client.jsm :: DC_onPacket :: line 492 JS frame :: chrome://global/content/devtools/dbg-transport.js :: LDT_send/<.run :: line 212 native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0 TEST-INFO | (xpcshell/head.js) | exiting test DBG-CLIENT: Error handling response: 2147500036 - stack: undefined resource://gre/modules/devtools/dbg-client.jsm:496: error: undefined undefined TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/devtools/debugger/tests/unit/head_dbg.js | head_dbg.js got console message: undefined undefined - See following stack: JS frame :: /Users/cltbld/talos-slave/test/build/xpcshell/head.js :: do_throw :: line 451 JS frame :: /Users/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/devtools/debugger/tests/unit/head_dbg.js :: listener.observe :: line 61 native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0 TEST-INFO | (xpcshell/head.js) | exiting test MOZ_EVENT_TRACE sample 1352429313710 39 <<<<<<<
The test is: do_check_neq(aResponse.profile.threads[0].samples.length, 0); So this means that despite the profiler running for 200ms, there was no sample. Benoit, any idea?
Component: Developer Tools: Debugger → Gecko Profiler
Product: Firefox → Core
Would increasing the timeout help? Do we expect to get hundreds of samples in 200ms?
(In reply to Panos Astithas [:past] from comment #2) > Would increasing the timeout help? Do we expect to get hundreds of samples > in 200ms? we should be getting around 200. I'm getting 198 on my machine.
My gut feeling for that bug is that the profiler isn't fully started. We spawn a different thread to do the signalling, I wonder if that thread is not up and running by then. We could solve the bug by blocking startProfiler on the first sample firing. Right now you start the profiler and the sampling thread will be up and running at some unknown point in the future. With this change we have the nice property that it's ready when we return from StartProfiler. Also I don't think this test should busy wait either. It should call setTimeout 0 or 5ms and poll the profile for data.
The point of the busy wait was to be sure we can identify something in the profile samples, and check that the right info is available in the frames data.
Ohh the test is actually checking the results is in this frame instead of just checking that we have random samples. That's lovely.
Whiteboard: [orange]
Whiteboard: [profiler]
Comment 20 to comment 28 are a different failure mode and different platform (and appear to have come across in the latest fx-team merge), so I've broken them out to bug 847314. Marking this bug as WFM for now, since whilst it's likely to be reopened in another few weeks, at least it will reduce the chance of mis-starring until bug 847314 is resolved.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Closing inactive keywords:intermittent-failure bugs where the TBPLbot has previously commented and the test isn't marked as disabled; filter on orange-cleanup-201401.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.