Closed Bug 949209 Opened 11 years ago Closed 11 years ago

make test-perf fails

Categories

(Firefox OS Graveyard :: Gaia, defect, P1)

x86_64
Linux
defect

Tracking

(b2g-v1.3T fixed)

RESOLVED FIXED
1.3 C1/1.4 S1(20dec)
Tracking Status
b2g-v1.3T --- fixed

People

(Reporter: hub, Assigned: alive)

References

Details

(Keywords: perf, regression, Whiteboard: [c=automation p=2 s= u=])

Attachments

(2 files, 1 obsolete file)

Apparently make test-perf fails on Hamachi.

I don't seem to get the source of the "apploadtime" event (e.target.src is null).
Keywords: perf
Whiteboard: [c=automation p= s= u=]
Priority: -- → P1
Actually it is not specific to hamachi.

It is likely caused by bug 907013.
Summary: make test-perf fails on Hamachi → make test-perf fails following the window manager changes (Bug 907013)
Whiteboard: [c=automation p= s= u=] → [c=automation p=1 s= u=]
Not so sure of the cause actually. But it is not specific to inari, that's for sure.
Summary: make test-perf fails following the window manager changes (Bug 907013) → make test-perf fails
I mean to hamachi as I reproduce on inari.
Git bisect show the first bad revision being a6c2af8d32274113e81d2c57e23d0621af118e53 which is bug 907013
See bug 936676
But, e.detail.manifestURL return null. Any idea?
Flags: needinfo?(alive)
Assignee: nobody → hub
Status: NEW → ASSIGNED
Keywords: regression
Whiteboard: [c=automation p=1 s= u=] → [c=automation p=2 s= u=]
Blocks: 947259
Can we rig |make test-perf| to run a subset of tests on travis just to ensure we have not broken it... We can migrate that into TBPL soon enough.
Flags: needinfo?(hub)
This sounds like an automation blocker, right? If so, please nominate this to block for the earliest release this bug applies to.
We have bug 936416 for datazilla. Yes that would be nice, but we might get lot of intermittent that we should fix. We can think of the subset, for sure.
(In reply to Jason Smith [:jsmith] from comment #8)
> This sounds like an automation blocker, right? If so, please nominate this
> to block for the earliest release this bug applies to.

I think it only impact master as the window manager refactor is only on master. 1.4? but then it is already blocking me on everything else.
blocking-b2g: --- → 1.4?
Flags: needinfo?(hub)
The error is 
      "stack": "{ name: 'TypeError',\n  stack: 'TypeError: Cannot call method \\'indexOf\\' of null\\n    at /home/hub/source/mozilla/B2G-inari/gaia/tests/performance/startup_test.js:53:23\\n    at Array.filter (native)\\n    at Context.<anonymous> (/home/hub/source/mozilla/B2G-inari/gaia/tests/performance/startup_test.js:51:23)\\n    at Test.Runnable.run (/home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runnable.js:211:32)\\n    at Runner.runTest (/home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runner.js:372:10)\\n    at /home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runner.js:448:12\\n    at next (/home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runner.js:297:14)\\n    at /home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runner.js:307:7\\n    at next (/home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runner.js:245:23)\\n    at /home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runner.js:269:7\\n    at Hook.Runnable.run (/home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runnable.js:213:5)\\n    at next (/home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runner.js:257:10)\\n    at /home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runner.js:269:7\\n    at done (/home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runnable.js:185:5)\\n    at /home/hub/source/mozilla/B2G-inari/gaia/node_modules/mocha/lib/runnable.js:197:9\\n    at Object.executeHook (/home/hub/source/mozilla/B2G-inari/gaia/node_modules/marionette-client/lib/marionette/client.js:370:18)\\n    at process._tickCallback (node.js:415:13)',\n  type: 'non_object_property_call',\n  constructorName: 'Error',\n  expected: null,\n  actual: null }",


Which is caused by e.target.src to be null.
e.detail.manifestURL is as well - that's the "recommended way" according to bug 936676 comment 8

And yes bug 907013 has landed since I'm hitting this now.
No longer blocks: 947259
Append window in the detail if it's custom.

Please try event.detail.window.manifestURL instead. Thanks!
Attachment #8347599 - Flags: review?(timdream)
Attachment #8347599 - Flags: feedback?(hub)
Flags: needinfo?(alive)
And get src by |event.detail.window.browser.element.src|
If you apply your patch and run |MARIONETTE_RUNNER_HOST=marionette-device-host RUNS=1 APP=sms make test-perf| with a device connected, b2g WILL freeze and be restarted...
Comment on attachment 8347599 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/14671

see my comment. - I believe it might be related to trying to serialize window back to the marionette client. ie it hits a bug in Gecko.

Note that if you do |detail.src = this.browser.element.src;| in your patch instead, I'm good with it.
Attachment #8347599 - Flags: feedback?(hub) → feedback-
Comment on attachment 8347599 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/14671

yup, works great. I still a local change in the test script. Maybe we could combine it. I'll attach the patch.
Attachment #8347599 - Flags: feedback?(hub) → feedback+
Please get that patch too for this PR.

https://github.com/hfiguiere/gaia/commit/ffaff1e649fc74665dd75d8917099fc6fe07a722

Thanks
Flags: needinfo?(alive)
Just to clarify this change in the test script is needed to deal with the change above. Together they fix the issue.
Attachment #8347599 - Flags: review?(timdream) → review+
https://github.com/mozilla-b2g/gaia/commit/ecb768890aafbb16d2a2eb1e24c3d662cd2a133a
Assignee: hub → alive
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: needinfo?(alive)
Resolution: --- → FIXED
Thanks !
Hey guys,

does that mean that the perf framework on master does not work with the apps on 1.3/1.2 etc now?
I think it's a pity but that's probably unavoidable. Maybe a notice about this on MDN could be useful though.
We could make it possible to have them work if need. Otherwise, yes I will add a note on MDN.
I got bit once already, but I don't think it's worth making it work on older phone. The tests will be specific to a Gaia version as well (except the most generic ones) so...
blocking-b2g: 1.4? → ---
in fact the fix should be easy.

see attached patch.
Attachment #8348854 - Attachment description: bug949209-2.diff → Propose backward compatibility fix.
Comment on attachment 8348854 [details] [diff] [review]
Propose backward compatibility fix.

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

looks good but I haven't tried it yet

::: tests/performance/performance_helper.js
@@ +59,4 @@
>          '}' +
>          'w.onapplicationloaded = function(e) {' +
>          '  var data = e.detail;' +
> +        '  if(data.src == null) data.src = e.target.src;' +

nit: `data.src = data.src || e.target.src;`
ok, I'll do that an a PR.
Attached file Backward compat fix
Attachment #8348854 - Attachment is obsolete: true
Attachment #8348864 - Flags: review?(felash)
Comment on attachment 8348864 [details] [review]
Backward compat fix

r=me
go go go !
Attachment #8348864 - Flags: review?(felash) → review+
Target Milestone: --- → 1.3 C1/1.4 S1(20dec)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: