925732 - Performance degrades when navigating to websites and eventually crashes

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Attachment: B2G Browser Perf Issue.mov

When running the b2gperf scrolling tests, the browser application becomes slow to respond and eventually crashes.

Steps to reproduce (requires Marionette enabled build):
1. Install b2gperf: pip install b2gperf==0.10
2. Connect the device to a WiFi network
3. Run: adb forward tcp:2828 tcp:2828
4. Run: b2gperf --delay=5 --log-level=DEBUG --test-type=scrollfps Browser

The test will load a long webpage, and scroll down/up. It will repeat this 30 times. I have attached a video of the issue, in which you can see that iteration 19 is much slower to type the URL than iteration 1. You will also see that at the end of iteration 19 when the browser app is closed, the homescreen app is no longer showing application icons, etc.

On iteration 23 you will see "Well, this is embarrassing. We tried to display this Web page, but it's not responding."

In our CI we can see this as a socket timeout, causing later tests to fail. It occurs for unagi, inari, and hamachi.

Comment 1

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Rob: Have you seen anything like this in the endurance tests?

Comment 2

[Jason Smith [:jsmith]]

Is this a recent regression? When was the last time this worked? When is the first time it failed?

Comment 3

[Dave Hunt [:davehunt] [he/him] ⌚BST]

The test in its current form has never passed on our Jenkins instance as far as I can tell. The previous version of the test last passed on September 20th, but considering the changes to the test and harness I would not consider this a valid comparison.

Comment 4

[Robert Wood [:rwood]]

Looking at the history, the browser_wifi endurance test did crash on Inari master Oct. 9 and 10th after 30 iterations (of starting the browser, loading a page, closing the browser, repeat). Sorry I missed that; the endurance tests are currently failing intermittently for another issue. I am trying to repro the browser problem. The browser_wifi endurance test has passed before on Inari master, the latest pass was October 1st (before the other intermittent issue started).

Comment 5

[Jason Smith [:jsmith]]

This is unlikely a browser bug - more likely a gecko bug.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

I wonder if this is related to bug 924565.

Comment 7

[Robert Wood [:rwood]]

I was able to reproduce this with the latest Inari master, using the browser_wifi endurance test. Typing the URL gets slower and slower and eventually (around iteration 30) the 'well this is embarrassing..." message appears immediately on browser start up, and the test fails with the socket timeout.

Comment 8

[Preeti Raghunath(:Preeti)]

Rob,

Are we suggesting if the issue is wifi or browser one?

Comment 9

[Robert Wood [:rwood]]

Hi Preeti, personally I would think it is a memory leak somewhere other than wifi, but someone in dev would need to verify. When I get a chance I will reproduce the issue and get some about_memory dumps and attach them here, which will help

Comment 10

[Mason Chang [Inactive] [:mchang]]

Hi Dave, it sounds like the test harness changed a lot between 1.2 and 1.1. Do you know if this test passed before on v1.1? If it did pass on 1.1, then we can koi+.

Thanks!

Comment 11

[Jason Smith [:jsmith]]

Removing koi until we confirm that this is a regression or not.

Comment 12

[Dave Hunt [:davehunt] [he/him] ⌚BST]

My inari is tied up with eideticker testing, is someone else able to run these tests against 1.1? b2gerf only targets 1.3 and 1.2 so it's possible this test won't even run on 1.1.

Comment 13

[Dave Hunt [:davehunt] [he/him] ⌚BST]

(In reply to Mason Chang from comment #10)
> Hi Dave, it sounds like the test harness changed a lot between 1.2 and 1.1.
> Do you know if this test passed before on v1.1? If it did pass on 1.1, then
> we can koi+.

I can say that a variation of the test certainly passed on 1.1 (open browser, load page, scroll). The way we load the page (now using the on-screen keyboard) and the way we perform the scroll (now scrolls slower) has changed though.

Comment 14

[Dave Hunt [:davehunt] [he/him] ⌚BST]

This is no longer occurring. Most likely fixed by a combination of bug 924565 and bug 909129.