Closed Bug 1096385 Opened 5 years ago Closed 4 years ago

Investigate failure in, call log is displayed erroneously


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

Gonk (Firefox OS)
Not set


(Not tracked)



(Reporter: viorela, Unassigned)




(2 files)

Attached image index.png
Test has failed on latest master build. 
From Jenkins screenshot it looks like the same received call is displayed 2 times in 'All' section.

I was not able to reproduce this failure locally by running the automated test or manually. 

Traceback (most recent call last):
File "/var/jenkins/2/workspace/flame-kk-319.mozilla-central.ui.functional.smoke/.env/local/lib/python2.7/site-packages/marionette_client-0.8.4-py2.7.egg/marionette/", line 264, in run
File "/var/jenkins/2/workspace/flame-kk-319.mozilla-central.ui.functional.smoke/tests/python/gaia-ui-tests/gaiatest/tests/functional/dialer/", line 73, in test_call_log_all_calls
self.wait_for_condition(lambda m: len(call_log.call_list) == 2)
File "/var/jenkins/2/workspace/flame-kk-319.mozilla-central.ui.functional.smoke/tests/python/gaia-ui-tests/gaiatest/", line 919, in wait_for_condition
Wait(self.marionette, timeout).until(method, message=message)
File "/var/jenkins/2/workspace/flame-kk-319.mozilla-central.ui.functional.smoke/.env/local/lib/python2.7/site-packages/marionette_client-0.8.4-py2.7.egg/marionette/", line 143, in until
TimeoutException: TimeoutException: Timed out after 30.4 seconds

Build info:
Device firmware (date) 	21 Oct 2014 00:59:42
Device firmware (incremental) 	40
Device firmware (release) 	4.4.2
Device identifier 	flame
Gaia date 	07 Nov 2014 11:08:20
Gaia revision 	5f8206bab97c
Gecko build 	20141110040206
Gecko revision 	d380166816dd
Gecko version 	36.0a1

Jenkins report:

We should work on trying to reproduce this issue.
QA Whiteboard: [fxosqa-auto-backlog+]
Assignee: nobody → robert.chira
QA Whiteboard: [fxosqa-auto-backlog+] → [fxosqa-auto-s5]
Attached file logcat.txt
I am still unable to reproduce the issue locally with manual or automated testing.
I started an adhoc run on Jenkins where the reproduction rate is 10 out of 21:

I cannot find any way for our test to cause this so I'm wondering if it's an intermittent bug.
Gabriele, do you know what could cause such a behavior?

I also attached a logcat from one of the times the test failed on Jenkins.
Flags: needinfo?(gsvelto)
The check where this times out is waiting for the two simulated calls to finish. The only way this would timeout is if - for some reason - one of the two calls doesn't finish correctly and is recorded to the call log. Or if it doesn't finish in time. This does look a lot like an intermittent, and it may be one caused by the tested code running for too long.
Flags: needinfo?(gsvelto)
Before we reach the wait that fails we wait for both calls to finish and I do not understand how this could cause one of the calls to appear twice in the call log (both appearing in the today group).
Flags: needinfo?(gsvelto)
This test has failed in latest v2.1 build, with the error described in comment 0:

Device firmware (date) 	03 Dec 2014 00:49:18
Device firmware (incremental) 	eng.cltbld.20141203.034907
Device firmware (release) 	4.4.2
Device identifier 	flame
Gaia date 	02 Dec 2014 17:43:51
Gaia revision 	dbaf3e31c9ba
Gecko build 	20141203001205
Gecko revision 	ebce587d2194
Gecko version 	34.0
QA Whiteboard: [fxosqa-auto-s5] → [fxosqa-auto-from-s5] [fxosqa-auto-s6]
I've double-checked the relevant code and it's horribly racy which is probably why two entries are being created instead of one. Moving to the dialer component.
Component: Gaia::UI Tests → Gaia::Dialer
Flags: needinfo?(gsvelto)
Assignee: robert.chira → nobody
QA Whiteboard: [fxosqa-auto-from-s5] [fxosqa-auto-s6] → [fxosqa-auto-from-s5] [fxosqa-auto-dropped-s6]
Depends on: 1112577
QA Whiteboard: [fxosqa-auto-from-s5] [fxosqa-auto-dropped-s6] → [fxosqa-auto-from-s5] [fxosqa-auto-dropped-s6] [fxosqa-auto-backlog+]
Any progress on this bug.
Many thanks.
Johan, could you please test if this problem went away now that bug 1112577 landed?
Flags: needinfo?(jlorenzo)
40/100 failures: 14 call which couldn't be made, 2 crashes and 1 manifestation of bug 1126260 and 27 call log. The issue doesn't seem to be fixed :(
Flags: needinfo?(jlorenzo)
With bug 1151627 now fixed this might be fixed too, Johan can you give this a spin again when you have some spare time?
Flags: needinfo?(jlorenzo)
Let's enable the test, I'll do that as part of the pull request in bug 1207646.
Depends on: 1207646
Thanks Martijn, I'll keep my eyes peeled for failures.
The pull request from bug 1207646 is merged now, so this test is re-enabled.
Optimistically calling this fixed. If it causes still failures, we can re-open.
Closed: 4 years ago
Resolution: --- → FIXED
Thanks for handling it Martijn! I'll watch the test too.
Flags: needinfo?(jlorenzo)
You need to log in before you can comment on or make changes to this bug.