Created attachment 815835 [details] 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.
Rob: Have you seen anything like this in the endurance tests?
Is this a recent regression? When was the last time this worked? When is the first time it failed?
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.
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).
This is unlikely a browser bug - more likely a gecko bug.
blocking-b2g: --- → koi?
Component: Gaia::Browser → General
Keywords: perf, regression
I wonder if this is related to bug 924565.
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.
Rob, Are we suggesting if the issue is wifi or browser one?
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
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!
Removing koi until we confirm that this is a regression or not.
blocking-b2g: koi? → ---
Whiteboard: [c= p= s= u=] [MemShrink] → [c=memory p= s= u=] [MemShrink]
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.
(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.
Whiteboard: [c=memory p= s= u=] [MemShrink] → [c=memory p= s= u=]
This is no longer occurring. Most likely fixed by a combination of bug 924565 and bug 909129.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [c=memory p= s= u=] → [c=memory p= s=2013.11.08 u=]
You need to log in before you can comment on or make changes to this bug.