Closed Bug 1067625 Opened 7 years ago Closed 6 years ago

[Calendar] Datazilla is missing calendar App when measuring moz-app-visually complete


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

Gonk (Firefox OS)
Not set


(b2g-v2.0 fixed, b2g-v2.0M fixed, b2g-v2.1 fixed, b2g-v2.2 fixed)

2.1 S8 (7Nov)
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.0M --- fixed
b2g-v2.1 --- fixed
b2g-v2.2 --- fixed


(Reporter: tchung, Assigned: Eli)



(Keywords: perf, Whiteboard: [priority])


(2 files)

[Blocking Requested - why for this release]:

When analyzing bug 1059349, i noticed that Calendar App has disappeared from datazilla testing results recently.   This is true for master, 2.0, and 2.1 branches at 319MB.  

Spoke to :Hub, and he investigated with the following information:

"It seems that there is a segfault occuring on the PC when running the
test for calendar.  That's what I can see in Jenkins. I have never been able to reproduce
that problem in the past but I have observed it in the wild - only on

The crash is NOT on the phone. It is on the PC. It is 'make' on Ubuntu.  Here is the original bug, we worked around it:   Those who have access to the jenkins machines, which exclude me. The A-Team I think."

Going to nominate this bug for detective work and why we arent getting calendar startup results for the Flame.   I can see data results returning if you set the filter to 60 days, but it doesnt appear at 30 days.
triage: internal metric, wouldn't block on this but I'm marking it priority and getting it on the schedule for sprint 5.
blocking-b2g: 2.1? → ---
Whiteboard: [priority]
Target Milestone: --- → 2.1 S5 (26sep)
Assignee: nobody → gaye
Target Milestone: 2.1 S5 (26sep) → 2.1 S6 (10oct)
[priority] --> tracking-b2g:+ conversion
tracking-b2g: --- → +
Target Milestone: 2.1 S6 (10oct) → 2.1 S7 (24Oct)
James, can you help repro this? Gaye isn't able to repro and we need someone to verify through mtv vpn.
Flags: needinfo?(jlal)
Target Milestone: 2.1 S7 (24Oct) → 2.1 S8 (7Nov)
Assignee: gaye → eperelman
Keywords: perf
The offending section of the console output:

node_modules installed.
touch -c node_modules
make[1]: Leaving directory `/var/jenkins/2/workspace/flame-kk-319.b2g-inbound.perf.gaia'

        throw err;
Error: Command failed: make: *** [app] Segmentation fault (core dumped)

    at ChildProcess.exithandler (child_process.js:647:15)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:753:16)
    at Socket.<anonymous> (child_process.js:966:11)
    at Socket.EventEmitter.emit (events.js:95:17)
    at Pipe.close (net.js:465:12)
calendar returned no output.
Blowing up at profile_builder.js trying to run what appears to be `make -C $GAIA_ROOT`.
Looks like the test is timing out right before running the Calendar performance test because the profile creation is now longer than 10 seconds. The performance script is a copy of the "gaia-marionette" script and was updated to 60 seconds back in January 2014, but this script was never updated.
Attachment #8516242 - Flags: review?(jlal)
Flags: needinfo?(jlal)
Attachment #8516242 - Flags: review?(jlal) → review+
Keywords: checkin-needed
Closed: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Requesting uplift of *performance-only* TEST-ONLY changes to v2.0 and v2.1. This has no effect on anything else but the timeout of performance tests.
Keywords: checkin-needed
While the timeouts fixed the issue I was having locally with this process, it still seems to fail on the Jenkins boxes. I'm currently debugging on the servers themselves to determine where the problem lies.
Resolution: FIXED → ---
Could I get one of you gents to review this patch? By ensuring profile creation happens in the bin script (which prior only happened for b2g-desktop-host), we can prevent the segfault that occurs on Linux when trying to run make test-perf without a profile-test directory.
Attachment #8518509 - Flags: review?(jlal)
Attachment #8518509 - Flags: review?(gaye)
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Looks like it broke again, any idea of what could be wrong?
Flags: needinfo?(eperelman)
Resolution: FIXED → ---
See Also: → 1079557
According to the logs:


Error: timeout exceeded!
	    at Object.Client.waitForSync (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/marionette-client/lib/marionette/client.js:693:16)
	    at Object.Client.waitFor (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/marionette-client/lib/marionette/client.js:661:60)
	    at Object.MarionetteHelper.waitForElement (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/marionette-helper/index.js:142:12)
	    at Object.PerfTestApp.launch (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/tests/performance/app.js:55:24)
	    at /var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/tests/performance/startup_events_test.js:57:11
	    at Object.PerformanceHelper.task (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/tests/performance/performance_helper.js:205:5)
	    at /var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/tests/performance/performance_helper.js:191:14
	    at Object.Client.waitForSync (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/marionette-client/lib/marionette/client.js:679:18)
	    at Object.Client.waitFor (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/marionette-client/lib/marionette/client.js:661:60)
	    at Object.Helper.delay (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/tests/js-marionette/helper.js:48:12)
	    at Object.PerformanceHelper.delay (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/tests/performance/performance_helper.js:213:22)
	    at trigger (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/tests/performance/performance_helper.js:190:12)
	    at Object.PerformanceHelper.repeatWithDelay (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/tests/performance/performance_helper.js:195:5)
	    at Context.<anonymous> (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/tests/performance/startup_events_test.js:54:23)
	    at callFn (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runnable.js:223:21)
	    at (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runnable.js:216:7)
	    at Runner.runTest (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runner.js:373:10)
	    at /var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runner.js:451:12
	    at next (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runner.js:298:14)
	    at /var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runner.js:308:7
	    at next (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runner.js:246:23)
	    at /var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runner.js:270:7
	    at done (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runnable.js:185:5)
	    at callFn (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runnable.js:228:7)
	    at (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runnable.js:216:7)
	    at next (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runner.js:258:10)
	    at /var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runner.js:270:7
	    at done (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runnable.js:185:5)
	    at /var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/mocha/lib/runnable.js:199:9
	    at Object.executeHook (/var/jenkins/1/workspace/flame-kk-319.b2g-inbound.perf.gaia/node_modules/marionette-client/lib/marionette/client.js:371:18)
	    at process._tickCallback (node.js:419:13)


It appears the test dies during the app.launch() method, specifically on the .waitForElement('body') call here:

var self = this;
this.client.apps.launch(this.origin, this.entryPoint, function(err, app) {
  if (app) {
    self.instance = app;

I find it really weird that it would die at this point, though, waiting for the body element. Any insight as to changes in the past couple months that would affect marionette's ability to find the body element?
Flags: needinfo?(eperelman)
Depends on: 1129069
tracking-b2g: + → ---
Datazilla is deprecated, and Calendar data is now displayed in Raptor.
Closed: 7 years ago6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.