1200271 - Regression test for bug 1190791 is still causing the Flame device to get stuck

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::UI Tests, defect)

Description

[Martijn Wargers (dead)]

In bug 1198264, I tried to get the regression test for bug 1190791 checked in. However, I still get this issue, using:
Build ID               20150831030202
Gaia Revision          31e595f86f6bf159b3a9a46816a6ac00a55ca9f9
Gaia Date              2015-08-30 00:42:30
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/f2518b8a7b97b5bb477e94bc9131584007aac887
Gecko Version          43.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150727.063909
Firmware Date          Mon Jul 27 06:39:20 EDT 2015
Bootloader             L1TC000118D0

The device gets stuck, the screen is black and the Marionette connection gets disconnected:
"
08-31 19:59:59.817 I/Gecko:DumpUtils( 3834): FifoWatcher::OpenFifo unlink failed; errno=2.  Continuing despite error.

The B2G process has restarted after crashing during  the tests so Marionette can't respond due to either a Gecko, Gaia or Marionette error. Above, the 5 most recent errors are listed. Check logcat for all errors if these errors are not the cause of the failure.
TEST-UNEXPECTED-ERROR | test_wifi_multiple_connect.py TestWiFiMultipleConnect.test_connect_and_forget_all_networks_2nd_run | IOError: Connection to Marionette server is lost. Check gecko.log (desktop firefox) or logcat (b2g) for errors.
"

I guess that means the regression from bug 1180596 is still in here, although not visible anymore during normal Gaia UI tests running.

Gary, can you investigate this, perhaps? Or give pointers on how to investigate this?

Comment 1

[Gary Chen [:xeonchen]]

If the root cause is like bug 1171827, I think bug 1194532 might fix this issue.

Comment 2

[Martijn Wargers (dead)]

Gary, but bug 1194532 is already fixed and this issue is still there, no?

Comment 3

[Cervantes Yu [:cyu] [:cervantes]]

I verified that mdnsd is already up to date on the build in question. Then I guess it's another bug.

Comment 4

[Martijn Wargers (dead)]

But I found the fix range of bug 1190791, using this regression test. I also used it for the regression range of bug 1172343. They correspond exactly with bug 1180596, e.g. the mdnsd work.

Comment 5

[Paul Yang [:pyang] (away)]

Martijn, do we have STR or test case name for this bug? Trying to help Gary to reproduce here.

Comment 6

[Gary Chen [:xeonchen]]

I'm not sure why this issue is related to mdnsd?
So I've made some experiments.

I can reproduce

  IOError: Connection to Marionette server is lost

by using following parameters:

  FLASH_BASEDIR=pvtbuilds/mozilla-central-flame-kk-eng/2015/09/2015-09-02-03-02-03/
  MTBF_CONF=conf/default_v300.json
  python mtbf_job_runner.py
  --testvars=MTBF-Driver/mtbf_driver/testvars.json
  --settings=tasks/task_flame.json

But cannot reproduce after installing my custom built gecko by following steps:

1. install gecko built on my computer (by |./flash gecko|)
2. change to shallow flash (without gecko) instead of full flash
3. re-run the test

Any idea?

Comment 7

[Martijn Wargers (dead)]

(In reply to Paul Yang [:pyang] from comment #5)
> Martijn, do we have STR or test case name for this bug? Trying to help Gary
> to reproduce here.

Sorry, I guess I should have made it more clear:
* Pull the pull request that I attached in bug 1198264: https://github.com/mozilla-b2g/gaia/pull/31535
git checkout -b mwargers-1198264 master
git pull https://github.com/mwargers/gaia.git 1198264
* Run the (Gaia UI) test, for me, the command is:
adb forward tcp:2828 tcp:2828 && gaiatest --type=b2g-dsds --address=localhost:2828  --testvars /Users/mwargers/B2G/testvars_home.json --restart tests/python/gaia-ui-tests/gaiatest/tests/functional/functional/test_wifi_multiple_connect.py

I used flash_pvt.py to flash the latest build.
Actually, it would be good to know if you can reproduce this on your Flame device, Paul.

Comment 8

[Martijn Wargers (dead)]

(In reply to Gary Chen [:xeonchen] from comment #6)
> I'm not sure why this issue is related to mdnsd?

The reason why I think this is related to mdnsd is because bug 1190791 occured exactly when the mdnsd was checked in and enabled and stopped being a problem when mdnsd was disabled (with a pref, right?) or backed out (which first happen while in bug 1172343, right?). See also bug 1190791, comment 9.
While bug 1172343 stopped happening, the test script also stopped from hanging the device, but after bug 1190791 was fixed, the test script is still causing the device to hang.

Comment 9

[Gary Chen [:xeonchen]]

(In reply to Martijn Wargers [:mwargers] (QA) from comment #7)
> I used flash_pvt.py to flash the latest build.
> Actually, it would be good to know if you can reproduce this on your Flame
> device, Paul.

I can reproduce using base image v18D_nightly_v4 + shallow_flash.
And the issue disappeared after pushing mdnsd to flame.

Comment 10

[Paul Yang [:pyang] (away)]

Looks like mdnsd did affect.  Wandering there's a way to see if it's turned on. Gary, any idea?

Comment 11

[Gary Chen [:xeonchen]]

Actually in comment 3 Cervantes already confirmed mdnsd's update.
Is this issue 100% reproducible?

Comment 12

[Martijn Wargers (dead)]

(In reply to Gary Chen [:xeonchen] from comment #9)
> (In reply to Martijn Wargers [:mwargers] (QA) from comment #7)
> > I used flash_pvt.py to flash the latest build.
> > Actually, it would be good to know if you can reproduce this on your Flame
> > device, Paul.
> 
> I can reproduce using base image v18D_nightly_v4 + shallow_flash.
> And the issue disappeared after pushing mdnsd to flame.

Ok, I guess you followed the steps in comment 7 then. Weird that I can still reproduce on my Flame then.

Comment 13

[Martijn Wargers (dead)]

Ok, I guess I had to do a full Flash of my Flame device then. After that, I can't reproduce the Flame getting stuck anymore. Thanks for your attentions!