[B2G][HERE Maps] HERE Maps is closed out by LMK when tapping "Nokia Beta Labs" link

VERIFIED FIXED in Firefox 34, Firefox OS v2.0

Status

P1
blocker
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: jdegeus, Assigned: sotaro)

Tracking

({memory-footprint, perf, regression})

unspecified
2.1 S4 (12sep)
ARM
Gonk (Firefox OS)
memory-footprint, perf, regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.0+, firefox33 wontfix, firefox34 fixed, firefox35 fixed, b2g-v1.4 unaffected, b2g-v2.0 verified, b2g-v2.0M verified, b2g-v2.1 verified, b2g-v2.2 verified)

Details

(Whiteboard: [2.0-exploratory][MemShrink:P1][c=memory p= s= u=2.0], URL)

Attachments

(10 attachments, 4 obsolete attachments)

129.98 KB, text/plain
Details
498.68 KB, text/plain
Details
86.76 KB, application/zip
Details
78.49 KB, application/zip
Details
101.79 KB, application/zip
Details
3.18 KB, text/plain
Details
6.09 KB, patch
sotaro
: review+
Details | Diff | Splinter Review
6.04 KB, patch
sotaro
: review+
Details | Diff | Splinter Review
23.27 KB, image/png
Details
3.03 MB, video/mp4
Details
(Reporter)

Description

4 years ago
Created attachment 8468135 [details]
dmesg.txt

Description:
When users are in the HERE Now app and viewing the "About" tab, if the user selects the "Nokia Beta Labs" link listed under the "Help make HERE Maps even better"

Setup: 
Navigate to Marketplace> Search "HERE Now"> Install app

Repro Steps:
1) Update a Flame to 20140805000238
2) Launch "HERE Now"
3) Select the Menu button on top right corner> About
4) Tap on "Nokia Beta Labs"
5) Observe app eventually closes resulting in LMK

Actual:
Tapping "Nokia BEta Labs" within About causes app result in LMK

Expected:
App does not close out due to LMK

Environmental Variables:
Device: Flame 2.0 (319mb)
Build ID: 20140805000238
Gaia: 597975839c04e0198eb98c2c77474f057b5531e7
Version: 32.0 (2.0)
Gecko: ddeead927143
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Repro frequency: 3/5
See attached: Video, dmesg and Logcat
dmesg.txt - logcat_About.txt - http://youtu.be/DX8SrUlA5s4
(Reporter)

Comment 1

4 years ago
Created attachment 8468137 [details]
logcat_About.txt

This issue DOES NOT occur on Flame 2.1 (319mb), Flame 2.0 (512mb), Flame 1.4 (319mb), Flame Base 122 (319mb), Flame Base 121-2 (319mb), Buri 2.1, Buri 2.0, Buri 1.4, Open C 2.1, Open C 2.0, and Open C 1.4

Actual: The app will not be closed out by LMK 

Flame 2.1 (319mb)

Environmental Variables:
Device: Flame Master
Build ID: 20140805040204
Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9
Gecko: 7f81be7db528
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0 (512mb)

Environmental Variables:
Device: Flame 2.0
Build ID: 20140805000238
Gaia: 597975839c04e0198eb98c2c77474f057b5531e7
Gecko: ddeead927143
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4 (319mb)

Environmental Variables:
Device: Flame 1.4
Build ID: 20140804183020
Gaia: 9377274b17200a60cebcd2427d489a7756c4cc72
Gecko: 24bc2ae19c59
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Flame Base 122 (319mb)

Environmental Variables:
Device: Flame 1.3 (319mb)
Build ID: 20140616171114
Gaia: e1b7152715072d27e0880cdc6b637f82fa42bf4e
Gecko: e181a36ebafaa24e5390db9f597313406edfc794
Version: 28.0 (1.3)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

Flame Base 121-2 (319mb)

Environmental Variables:
Device: Flame 1.3
Build ID: 20140610200025
Gaia: e106a3f4a14eb8d4e10348efac7ae6dea2c24657
Gecko: b637b0677e15318dcce703f0358b397e09b018af
Version: 28.0 (1.3)
Firmware Version: v121-2
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

Buri 2.1

Environmental Variables:
Device: Buri Master
Build ID: 20140805073149
Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9
Gecko: 2aaedcdf69f6
Version: 34.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Buri 2.0

Environmental Variables:
Device: Buri 2.0
Build ID: 20140805063011
Gaia: 4959d1eb92fa82198409c90f471aad6d68c463b3
Gecko: c18fb97addb8
Version: 32.0 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 1.4

Environmental Variables:
Device: Buri 1.4
Build ID: 20140804183020
Gaia: 9377274b17200a60cebcd2427d489a7756c4cc72
Gecko: 24bc2ae19c59
Version: 30.0 (1.4)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Open C 2.1

Environmental Variables:
Device: Open_C Master
Build ID: 20140805040204
Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9
Gecko: 7f81be7db528
Version: 34.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Open C 2.0 

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140805000238
Gaia: 597975839c04e0198eb98c2c77474f057b5531e7
Gecko: ddeead927143
Version: 32.0 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open C 1.4

v1.4 Environmental Variables:
Device: Open_C v1.4 MOZ
BuildID: 20140728000238
Gaia: 0a864988f5dce7f9f3dea9609e8ef054679c30ff
Gecko: 2da96d621030
Version: 32.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
Flags: needinfo?(ktucker)
(Reporter)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage?]
Keywords: regression
[Blocking Requested - why for this release]:

Since this is a regression from 1.4 and the app is being force closed, I'm nominating 2.0?
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?]
Component: Preinstalled B2G Apps → Gaia::System::Window Mgmt
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Product: Tech Evangelism → Firefox OS
Summary: [B2G][Tech Evangelism][HERE Maps] HERE Maps is closed out by LMK when tapping "Nokia Beta Labs" link within About → [B2G][HERE Maps] HERE Maps is closed out by LMK when tapping "Nokia Beta Labs" link

Updated

4 years ago
Component: Gaia::System::Window Mgmt → Performance
Keywords: footprint, perf
Whiteboard: [2.0-exploratory] → [2.0-exploratory][MemShrink]
Blocking given this is a regression in 2.0 and impacts a critical app not a TE issue.
blocking-b2g: 2.0? → 2.0+
Does this still reproduce on builds 20140806 and newer?  I'm just wondering if bug 1045680 helps.
I'm unable to reproduce this LMK on today's build in 319MB following STR. Repro rate 0/5.
I also tried a 2.0 build on 8/5 when this bug was filed and couldn't repro either.
Removing window-wanted tag and adding qawanted so others could try to repro.
Keywords: regressionwindow-wanted → qawanted
I was able to reproduce this issue on today's 2.0 build as well as the reporter's build.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140807094215
Gaia: bb3d2cf36c10f7186899431d4a21a2489864d9c6
Gecko: 4ad32f9626ad
Version: 32.0 (2.0) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
returning Regression-Window-Wanted based on the ability to repro
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
QA Contact: jmercado
I was also able to reproduce this issue on 2.1 Flame.

Environmental Variables:
Device: Flame Master
BuildID: 20140805081353
Gaia: e93780f9da8b34f370a4113abd4df9780d58e443
Gecko: b50bb656674e
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

1.4 Flame did not reproduce though.

Environmental Variables:
Device: Flame 1.4
BuildID: 20140807110116
Gaia: e9dce1f60f729e228810f751417681b5ff937b6b
Gecko: 509ebd2e22f7
Version: 30.0 (1.4) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
status-b2g-v2.1: unaffected → affected
Mozilla-inbound Regression Window

Last working 
Environmental Variables:
Device: Flame Master
BuildID: 20140429163002
Gaia: db3bcec51a361daddb7d3d4ba4d8a2a664b7b6aa
Gecko: de19c62cbc6b
Version: 32.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0



First Broken 
Environmental Variables:
Device: Flame Master
BuildID: 20140429193004
Gaia: db3bcec51a361daddb7d3d4ba4d8a2a664b7b6aa
Gecko: c0d658d3f739
Version: 32.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Last working gaia / First broken gecko - Issue DOES occur
Gaia: db3bcec51a361daddb7d3d4ba4d8a2a664b7b6aa
Gecko: c0d658d3f739

First broken gaia / Last working gecko - Issue does NOT occur

Gecko Pushlog:  https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=de19c62cbc6b&tochange=c0d658d3f739
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
Well, bisecting with a flame using low-memory profile is likely to point at that commit.  It uses a heuristic based on screen size.  As far as I know we do nothing to reduce the high dpi of the device when we restrict its memory.  So the heuristic is probably wrong for such a device.  That may not be representative of real devices, though.

It seems to me skia just started using a lot more memory at some point as reflected in bugs like bug 990174.  That should be root caused.
SkiaGL uses more memory and makes things go faster.  Every time we make a change that pushes more scenarios into SkiaGL (increasing the maximum size, decreasing the minimum size) or increase the maximum size of the SkiaGL cache, we will use more memory.  It's a feature.  And then, there are the memory leaks, bug 990174 potentially being one of them.
Just turn off SkiaGL completely, and see if the problem goes away? Set gfx.canvas.azure.accelerated to false.
(In reply to Milan Sreckovic [:milan] (PTO 8/11 - 8/15) from comment #12)
> cache, we will use more memory.  It's a feature.  And then, there are the
> memory leaks, bug 990174 potentially being one of them.
> Just turn off SkiaGL completely, and see if the problem goes away? Set
> gfx.canvas.azure.accelerated to false.

From what I understand we import new skia versions regularly.  Do we have any tests to catch memory regressions when we do this?  It seems like bug 990174 and the issue it blocks started around one of these imports.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)

Updated

4 years ago
Severity: normal → blocker
Priority: -- → P1
Whiteboard: [2.0-exploratory][MemShrink] → [2.0-exploratory][MemShrink][c=memory p= s= u=2.0]
See Also: → bug 1049195
Triage: Since this is a third party app, Harold can you please take a look at this?
Flags: needinfo?(hkirschner)
I misread the comments, since this is a regression in gecko, this is our responsibility.
Flags: needinfo?(hkirschner)

Comment 16

4 years ago
(In reply to Ben Kelly [:bkelly] from comment #13)
> (In reply to Milan Sreckovic [:milan] (PTO 8/11 - 8/15) from comment #12)
> > cache, we will use more memory.  It's a feature.  And then, there are the
> > memory leaks, bug 990174 potentially being one of them.
> > Just turn off SkiaGL completely, and see if the problem goes away? Set
> > gfx.canvas.azure.accelerated to false.
> 
> From what I understand we import new skia versions regularly.  Do we have
> any tests to catch memory regressions when we do this?  It seems like bug
> 990174 and the issue it blocks started around one of these imports.

Milan, do you have any idea about this? Looks like you're on PTO. Ni you to make sure you're aware of the comment made by Ben. 

Thanks.
Flags: needinfo?(milan)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][2.0-signoff-need]

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+][2.0-signoff-need] → [QAnalyst-Triage+][2.0-signoff-need+]
I was trying to reproduce this, and there's once HERE gets LMKed after I tap "share". It seems memory was consumed very fast, which not only HERE but alsy Marketplace and Homescreen were killed at the same time.

I haven't reproduced the same symptom of this bug.
Don't know of anything in particular that tries to catch increased memory usage with canvas and new versions of SkiaGL.  I'm not sure if this is still reproducible, but if it is, see my comment 12 for something to try to make sure it is SkiaGL caching that is causing trouble here.
Flags: needinfo?(milan)

Comment 19

4 years ago
Hi Jayme, according to comment 17 and comment 18, can you set gfx.canvas.azure.accelerated to false and try again? Thanks.
Flags: needinfo?(jmercado)
QA Wanted for comment 19
QA Whiteboard: [QAnalyst-Triage+][2.0-signoff-need+] → [2.0-signoff-need+]
Keywords: qawanted
I just managed to repro now, set high resolution map in preference menu will make it easily reproduced (even without tapping "Nokia Beta Labs"). /d/kgsl/proc/[pid]/mem shows kgsl texture taking dozens of MBs like bug 1049195.

Should I mark this a dup direclty or have QA's double confirm?
Removing the needinfo? request on me since there is a qawanted tag.  If someone else from the qawanted team can handle this sooner that would be great.
Flags: needinfo?(jmercado) → needinfo?(jmitchell)
Jayme - that is fine
Flags: needinfo?(jmitchell)
Whiteboard: [2.0-exploratory][MemShrink][c=memory p= s= u=2.0] → [2.0-exploratory][MemShrink:P1][c=memory p= s= u=2.0]
Marking DUP per comment #21.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1049195

Updated

4 years ago
Keywords: qawanted
(Assignee)

Comment 25

4 years ago
I do not think this is a dup of bug 1049195, even though the problems started to happen by using SkiaGL in the STR. From Comment 8, this bug's problem happens also on b2g-v2.1. But bug 1049195 happens only on b2g v2.0.

And bug 1049195 needs only "HERE Maps" process alive, but this bug needs Browser and "HERE Maps" processes need to be alive and Browser is in the Top.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Updated

4 years ago
Assignee: nobody → sotaro.ikeda.g
(Assignee)

Updated

4 years ago
Depends on: 1049195
(Assignee)

Comment 26

4 years ago
From Bug 1049195 Comment 55, I tested to call glFlush() for each draw calls. But the "HERE Maps" was occasionally killed by LMK.
(Assignee)

Comment 27

4 years ago
I confirmed a wired thing. Even when SkiaGL is disabled, I still saw the crash.
(Assignee)

Comment 28

4 years ago
The following the code is the code to open "Nokia Beta Labs".

> <a href="https://betalabs.nokia.com/apps/nokia-maps-for-mobile-web/forum" class="forumlink" target="_blank" onclick="if(event._fake) {event.preventDefault();event.stopPropagation();}">Nokia Beta Labs</a>

It trigger browser app's tab open and the "HERE Maps" app is set to background state. The "HERE Maps"'s state is just a normal background app. Within background apps, more recently used app has higher priority.
But it's priority is lower than background Homescreen.

Application's priority becomes the following.
 Foreground app > background homescreen > most recently used background app > other background apps.

Therefore, this bug requests three apps "one browser tab"(foreground), homescreen, HERE Maps(background) are alive during the STR.


More precise priority is defined by the following.
  http://mxr.mozilla.org/mozilla-central/source/hal/HalTypes.h#81
(Assignee)

Comment 29

4 years ago
This bug says that RAM usage is increased since v1.4. But the b2g system does not ensure/require that the most recently used background app is always alive.
(Assignee)

Comment 30

4 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #27)
> I confirmed a wired thing. Even when SkiaGL is disabled, I still saw the
> crash.

I modified wrong code:-( I am going to confirm it again.
(Assignee)

Comment 31

4 years ago
I re-confirmed that HERE Maps was killed even when SkiaGL was disabled.
(Assignee)

Comment 32

4 years ago
By using "adb shell b2g-ps -p", I check process/memory states of the followings. On b2.0, HERE Maps was killed even with SkiaGL was disabled. When SkiaGL is enabled, HERE Maps is killed more often than disabled.
- b2g-v1.4 flame 319MB
- b2g-2.0 SkiaGL enabled(before HERE Maps killed) flame 319MB
- b2g-2.0 SkiaGL disabled(before HERE Maps killed) flame 319MB


** b2g-v1.4 flame 319MB **

APPLICATION      USER     PID   PPID  VSIZE  RSS   PRIO  NICE  RTPRI SCHED
b2g              root      290   1     237308 37544 20    0     0     0     
(Nuwa)           root      906   290   53364  4952  20    0     0     0     
Homescreen       u0_a967   967   906   72052  11412 38    18    0     0     
HERE Maps        u0_a1204  1204  906   79620  19848 38    18    0     0     
(Preallocated a  u0_a1255  1255  906   60536  6716  38    18    0     0     
Browser          u0_a1300  1300  290   76312  8764  38    18    0     0     
Browser          u0_a1656  1656  290   78104  9856  38    18    0     0     
Browser          u0_a1704  1704  290   78040  9864  38    18    0     0     
Browser          u0_a1747  1747  290   78040  15436 38    18    0     0     
Browser          u0_a1804  1804  290   87136  34928 21    1     0     0     
  
** b2g-2.0 SkiaGL enabled(before HERE Maps killed) flame 319MB **

APPLICATION    SEC USER     PID   PPID  VSIZE  RSS   PRIO  NICE  RTPRI SCHED
b2g              0 root      2314  1     231832 45164 20    0     0     0  
(Nuwa)           0 root      2412  2314  54964  2232  20    0     0     0 
Homescreen       2 u0_a3081  3081  2412  78676  12528 38    18    0     0 
HERE Maps        2 u0_a3406  3406  2412  119392 44672 27    7     0     0 
Browser          2 u0_a3467  3467  2412  81488  26576 21    1     0     0 
(Preallocated a  0 u0_a3506  3506  2412  59124  9504  38    18    0     0 

** b2g-2.0 SkiaGL disabled(before HERE Maps killed) flame 319MB ** 

APPLICATION    SEC USER     PID   PPID  VSIZE  RSS   PRIO  NICE  RTPRI SCHED
b2g              0 root      292   1     226660 63272 20    0     0     0
(Nuwa)           0 root      852   292   54964  8932  20    0     0     0
Homescreen       2 u0_a879   879   852   76620  23184 38    18    0     0
HERE Maps        2 u0_a1206  1206  852   76772  25160 38    18    0     0
Browser          2 u0_a1630  1630  852   79060  27608 21    1     0     0
(Preallocated a  2 u0_a1656  1656  852   61176  15380 38    18    0     0
(Assignee)

Comment 33

4 years ago
On b2g-v1.4, a lot of browser tabs were alive. But on b2g, only one Borwser Tab was alive, even when SkiaGL was disabled. And all b2g-v1.4's processes uses less memory compared to b2g-v2.0.
(Assignee)

Comment 34

4 years ago
Created attachment 8481587 [details]
about-memory b2g-v1.4
(Assignee)

Comment 35

4 years ago
Created attachment 8481588 [details]
about-memory disable SkiaGL b2gv2.0
(Assignee)

Comment 36

4 years ago
On b2g-v2.0, when just start the STR, there is a case that multiple Browser tab's processes exist. All browser tab's rss seems a lot bigger than b2g-v1.4. On 1.4, active Tab's RSS is big, but other browser tab's process' RSS is small.

** b2g-2.0 SkiaGL disabled(before HERE Maps killed) flame 319MB ** 

APPLICATION    SEC USER     PID   PPID  VSIZE  RSS   PRIO  NICE  RTPRI SCHED
b2g              0 root      279   1     221968 65140 20    0     0     0 
(Nuwa)           0 root      867   279   54964  9308  20    0     0     0 
Homescreen       2 u0_a905   905   867   76612  23684 38    18    0     0 
HERE Maps        2 u0_a1211  1211  867   75748  28020 38    18    0     0  
Browser          2 u0_a1359  1359  867   73824  26080 38    18    0     0  
Browser          2 u0_a1408  1408  867   73504  26456 38    18    0     0   
Browser          2 u0_a1442  1442  867   79316  28200 21    1     0     0   
(Preallocated a  2 u0_a1484  1484  867   61112  16036 38    18    0     0
(Assignee)

Comment 37

4 years ago
Created attachment 8481611 [details]
about-memory disable SkiaGL b2gv2.0 with multiple browser tabs
(Assignee)

Comment 38

4 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #36)
> On b2g-v2.0, when just start the STR, there is a case that multiple Browser
> tab's processes exist. All browser tab's rss seems a lot bigger than
> b2g-v1.4. On 1.4, active Tab's RSS is big, but other browser tab's process'
> RSS is small.

On b2g-v2.0, when RAM size setting is changed from 319MB to 340MB, browser tab's process' shrink was also observed.
(Assignee)

Comment 39

4 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #38)
> 
> On b2g-v2.0, when RAM size setting is changed from 319MB to 340MB, browser
> tab's process' shrink was also observed.

But the shrink is not big enough compared to b2g-v1.4(319MB).

On b2g-v2.0(RAM was 340MB) the result was following.
- SkiaGL On: HERE Maps was killed by the STR
- SkiaGL Off: HERE Maps was not killed by the STR
(Assignee)

Comment 40

4 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #32)
> By using "adb shell b2g-ps -p", I check process/memory states of the
> followings. On b2.0, HERE Maps was killed even with SkiaGL was disabled.
> When SkiaGL is enabled, HERE Maps is killed more often than disabled.
> - b2g-v1.4 flame 319MB
> - b2g-2.0 SkiaGL enabled(before HERE Maps killed) flame 319MB
> - b2g-2.0 SkiaGL disabled(before HERE Maps killed) flame 319MB
> 
> 
> ** b2g-v1.4 flame 319MB **
> 
> APPLICATION      USER     PID   PPID  VSIZE  RSS   PRIO  NICE  RTPRI SCHED
> b2g              root      290   1     237308 37544 20    0     0     0     
> (Nuwa)           root      906   290   53364  4952  20    0     0     0     
> Homescreen       u0_a967   967   906   72052  11412 38    18    0     0     
> HERE Maps        u0_a1204  1204  906   79620  19848 38    18    0     0     
> (Preallocated a  u0_a1255  1255  906   60536  6716  38    18    0     0     
> Browser          u0_a1300  1300  290   76312  8764  38    18    0     0     
> Browser          u0_a1656  1656  290   78104  9856  38    18    0     0     
> Browser          u0_a1704  1704  290   78040  9864  38    18    0     0     
> Browser          u0_a1747  1747  290   78040  15436 38    18    0     0     
> Browser          u0_a1804  1804  290   87136  34928 21    1     0     0     

khuey, on b2g-v1.4 flame, background's Browser tab's rss' were gradually decreased. Were they swapped out to zram? Or, are they decreased by other reason? Thanks.
Flags: needinfo?(khuey)
(Assignee)

Comment 41

4 years ago
In the STR, when more than 4 Browser Tab's were opened, their RSS stared to decreased. On b2g-v2.0 flame(319MB), in the STR, at most 3 Browser Tabs were opened. Therefore, I did not saw Browser Tabs RSS decrease on b2g-v2.0 flame(319MB).
(Assignee)

Comment 42

4 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #31)
> I re-confirmed that HERE Maps was killed even when SkiaGL was disabled.

On latest v2.0, just disabling SkiaGL does not fix the problem, though it makes the symptom better. It seems better to handle canvas 2d's memory usage problem in a different bug.
(Assignee)

Comment 43

4 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #42)
> On latest v2.0, just disabling SkiaGL does not fix the problem, though it
> makes the symptom better. It seems better to handle canvas 2d's memory usage
> problem in a different bug.

But it just means that disabling SkiaGL on low memory device(less than 319MB) when the canvas size is larger than its screen size. It is partial revert of Bug 999841. It disable SkiaGL on some condition on low memory device, but it is not a regression since b2g-v1.4.
(Assignee)

Updated

4 years ago
Depends on: 1042305
(Assignee)

Comment 44

4 years ago
Bug 1042305 improve the situation. On latest v2.0. The problem happens when I opened 5th Browser Tab in the STR in Comment 0.
(Assignee)

Updated

4 years ago
Depends on: 1060790
(Assignee)

Comment 45

4 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #44)
> Bug 1042305 improve the situation. On latest v2.0. The problem happens when
> I opened 5th Browser Tab in the STR in Comment 0.

When SkiaGL is disabled, the problem happens when I opened 8th-10th Browser Tabs on Flame(319MB). Therefore, Skia seems to use less RAM than SkiaGL, but on latest v2.0 does not fix the problem even with SkiaGL is disabled.
(Assignee)

Updated

4 years ago
Depends on: 1061943
They might be swapped out.  b2g-info will tell you that.
(Assignee)

Updated

4 years ago
Depends on: 1062361
(Assignee)

Comment 47

4 years ago
I talked with milan offline. We agreed to disable SkiaGL if canvas size is larger than screen size on low memory device.
(In reply to Sotaro Ikeda [:sotaro] from comment #47)
> I talked with milan offline. We agreed to disable SkiaGL if canvas size is
> larger than screen size on low memory device.

Don't we already do this?  I tried to add it here:

http://dxr.mozilla.org/mozilla-central/source/dom/canvas/CanvasRenderingContext2D.cpp#864
(Assignee)

Comment 49

4 years ago
Yhea, that code already do almost all. We need to add disabling SkiaGL from screen size to 980*480 on low memory devices.
(In reply to Sotaro Ikeda [:sotaro] from comment #49)
> Yhea, that code already do almost all. We need to add disabling SkiaGL from
> screen size to 980*480 on low memory devices.

Ok, then lets make sure people don't expect games or apps like FishIETank's mobile version to run at high fps on these devices.
(Assignee)

Comment 51

4 years ago
I tested on v2.0 flame JB about how much memory is necessary to fix the problem. When flame's total memory was 350MB, the problem was fixed and total system memory size was 243MB.

- 319MB: Total System Memory size: 213MB
- 330MB: Total System Memory size: 224MB
- 350MB: Total System Memory size: 243MB
(Assignee)

Comment 52

4 years ago
Frame's screen size is 480*854 and default scale is 1.5. Then, 720*1281 becomes SkiaGL usage's threshold. On low memory device, SkiaGL need to be disabled if the canvas size is more than screen buffer size.
Keep in mind our default displayport is 480*980, even if its bigger than the physical screen.
(Assignee)

Comment 54

4 years ago
I am not sure why CanvasRenderingContext2D::CheckSizeForSkiaGL() cares about a default scale. Flame has 1.5 default scale. But if I create an application that have 480*854 size canvas. The canvas was always fullscreen size(not scaled) except APZ was enabled. Application did not scale canvas size except APZ is enabled.

AppUnits to GfxUnits transform is done by nsPresContext::AppUnitsToGfxUnits(). 
> nsPresContext::AppUnitsToGfxUnits()
> ->nsDeviceContext::AppUnitsToGfxUnits()
> ->nsDeviceContext::AppUnitsPerDevPixel()
> ->return nsDeviceContext::mAppUnitsPerDevPixel;

nsDeviceContext::mAppUnitsPerDevPixel is initialized to 1.5 at first. But it is soon overrided to 1.0 by nsPresContext::Init().
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp#960

Therefore canvas always seems rendered by 1.0 scale by default except APZ enabled.
(Assignee)

Comment 55

4 years ago
bkelly, snorp can you comment to Comment 54?
Flags: needinfo?(snorp)
Flags: needinfo?(bkelly)
(Assignee)

Comment 56

4 years ago
kats, do you know about Comment 54?
Flags: needinfo?(bugmail.mozilla)
(Assignee)

Comment 57

4 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #54)
> I am not sure why CanvasRenderingContext2D::CheckSizeForSkiaGL() cares about
> a default scale. Flame has 1.5 default scale. But if I create an application
> that have 480*854 size canvas. The canvas was always fullscreen size(not
> scaled) except APZ was enabled. Application did not scale canvas size except
> APZ is enabled.
> 
> AppUnits to GfxUnits transform is done by
> nsPresContext::AppUnitsToGfxUnits(). 
> > nsPresContext::AppUnitsToGfxUnits()
> > ->nsDeviceContext::AppUnitsToGfxUnits()
> > ->nsDeviceContext::AppUnitsPerDevPixel()
> > ->return nsDeviceContext::mAppUnitsPerDevPixel;
> 
> nsDeviceContext::mAppUnitsPerDevPixel is initialized to 1.5 at first. But it
> is soon overrided to 1.0 by nsPresContext::Init().

Correction.
nsDeviceContext::mAppUnitsPerDevPixel is 40(60/1.5) at first.
(Assignee)

Comment 58

4 years ago
Created attachment 8487183 [details] [diff] [review]
patch - Partially disable SkiaGL on Low total system memory
(Assignee)

Comment 59

4 years ago
Created attachment 8487185 [details] [diff] [review]
patch for b2gv2.0 - Partially disable SkiaGL on Low total system memory
(Assignee)

Comment 60

4 years ago
By applying the patch, SkiaGL is disabled in HERE Maps on flame(319MB). It change the symptom better. But the problem is still exist. graphics memory usage is already minimized. b2gv2.0's memory usage is very high than b2gv1.4. This seems not a graphics problem, but general memory usage problem.

After the canvas' fix. If this is still judged as a blocker of b2gv2.0. It seems better to handle the problem as a different bug.
(Assignee)

Updated

4 years ago
Attachment #8487183 - Flags: review?(jmuizelaar)
(In reply to Sotaro Ikeda [:sotaro] from comment #54)
> I am not sure why CanvasRenderingContext2D::CheckSizeForSkiaGL() cares about
> a default scale. Flame has 1.5 default scale. But if I create an application
> that have 480*854 size canvas. The canvas was always fullscreen size(not
> scaled) except APZ was enabled. Application did not scale canvas size except
> APZ is enabled.

I'm sorry, I don't remember exactly.  I seem to recall it was suggested by :kats and :mwu. See bug 999841 comment 8.
Flags: needinfo?(bkelly)
I don't really recall anything about this. I looked at the IRC conversation I think that comment is referencing [1] and I don't see anything about default-scale values in there. Maybe I found the wrong conversation since that one didn't have mwu.

[1] http://logs.glob.uno/?c=mozilla%23gfx&s=28+Apr+2014&e=28+Apr+2014#c163463
Flags: needinfo?(bugmail.mozilla)
Created attachment 8487246 [details]
old irc conversation

Ah, I think I found the conversation in question. From the sounds of what mwu was saying it looks like the 1.5 device scale was being applied, which contradicts what sotaro was saying in comment 54. Or maybe the device scale is ignored in fullscreen mode and mwu wasn't viewing in fullscreen? I don't really know.
(Assignee)

Comment 65

4 years ago
mwu, do you know something about Comment 64?
Flags: needinfo?(mwu)
(Assignee)

Updated

4 years ago
Flags: needinfo?(snorp)

Comment 66

4 years ago
Sotaro, I think the 1.5x scaling was for pages doing 100% x 100% sized canvases without a meta viewport tag. Not 100% sure. I was also testing in a browser, so it wasn't fullscreen, if that makes any difference.
Flags: needinfo?(mwu)
(Assignee)

Comment 67

4 years ago
Thanks, it becomes clear.
Comment on attachment 8487183 [details] [diff] [review]
patch - Partially disable SkiaGL on Low total system memory

Review of attachment 8487183 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/canvas/CanvasRenderingContext2D.cpp
@@ +889,5 @@
>    static int32_t gScreenPixels = -1;
>    if (gScreenPixels < 0) {
>      // Default to historical mobile screen size of 980x480.  In addition,
>      // allow skia use up to this size even if the screen is smaller.  A lot
>      // content expects this size to work well.

Add a comment here about which content this is referring to.

@@ +929,2 @@
>      }
>    }

Let's just always have a scale of 1.0. We can always change this if we find a lot of content that needs it.
Attachment #8487183 - Flags: review?(jmuizelaar) → review+
(Assignee)

Comment 69

4 years ago
Created attachment 8488062 [details] [diff] [review]
patch - Partially disable SkiaGL on Low total system memory

Apply the comments. Carry "r= jrmuizel".
Attachment #8487183 - Attachment is obsolete: true
Attachment #8488062 - Flags: review+
(In reply to Jeff Muizelaar [:jrmuizel] from comment #68)
> >      // Default to historical mobile screen size of 980x480.  In addition,
> >      // allow skia use up to this size even if the screen is smaller.  A lot
> >      // content expects this size to work well.
> 
> Add a comment here about which content this is referring to.

If I understand correctly, this is practically all content on mobile that uses device width/height because we default out display port 980x480.

> Let's just always have a scale of 1.0. We can always change this if we find
> a lot of content that needs it.

Well, I'm fairly certain not using the real scale broke the FishIETank benchmark and other GL games performance.  That's why I was asked to add it in bug 999841.
(Assignee)

Comment 71

4 years ago
Created attachment 8488071 [details] [diff] [review]
patch for b2gv2.0 - Partially disable SkiaGL on Low total system memory
Attachment #8487185 - Attachment is obsolete: true
Attachment #8488071 - Flags: review+
(Assignee)

Comment 72

4 years ago
(In reply to Ben Kelly [:bkelly] from comment #70)
> > Let's just always have a scale of 1.0. We can always change this if we find
> > a lot of content that needs it.
> 
> Well, I'm fairly certain not using the real scale broke the FishIETank
> benchmark and other GL games performance.  That's why I was asked to add it
> in bug 999841.

Are you going to say canvas2d Game? WebGL is different.
Sorry, I mispoke.  I meant canvas related games.
(Assignee)

Comment 74

4 years ago
Created attachment 8488094 [details] [diff] [review]
patch - Partially disable SkiaGL on Low total system memory

Fix nits.
Attachment #8488062 - Attachment is obsolete: true
Attachment #8488094 - Flags: review+
(Assignee)

Comment 75

4 years ago
Created attachment 8488095 [details] [diff] [review]
patch for b2gv2.0 - Partially disable SkiaGL on Low total system memory

Fix nits.
Attachment #8488071 - Attachment is obsolete: true
Attachment #8488095 - Flags: review+
(Assignee)

Comment 76

4 years ago
I checked a canvas size on popular game applications on Firefox Marketplace. All application's game canvas sizes except "Penguin Pop" were smaller than Flame's display size. Though there are some cases that the max canvas size is more than display size.

<Canvas size on Flame(854*480)>

- Pacman Canvas (Beta):
     + max canvas size: 540*390
- Penguin Pop:
     + max canvas size: 700*881
- Zombie Apocalypse
     + game screen canvas: 320*545
     + max canvas size: 480*690
- CutTheRope
     + max canvas size: 480*320
- Candy Crush
     + max canvas size: 639*567
- Slice Fruits
     + max canvas size: 512*512
- Rooftops
     + max canvas size: 480*300
- Blozzle
     + canvas 2d seems not used
- Pasjans/Solitaire
     + canvas 2d seems not used
- AirCombat
     + max canvas size: 320*480
- Fruit Cut Ninja
     + game screen canvas: 320*480
     + max canvas size: 480*818
- DuckShooting
     + canvas 2d seems not used
- BlockedCar
     + game screen canvas: 320*569
     + max canvas size:800*1200
- Chess
     + max canvas size: 304*304
- Hora de la aventura
     + canvas 2d seems not used
- Finger Print
     + canvas 2d seems not used
- GoldNuggets
     + canvas 2d seems not used
- Tulis Farm
     + canvas 2d seems not used
(Assignee)

Comment 77

4 years ago
I checked FishIEtank on flame.

On portrait, at first canvas size was small. It seems Bug 1059483. In this case, the canvas size was 320*451. By using pinch zoon, the canvas becomes bigger.When the canvas fit to screen, the canvas size was 980*1380. on Landscape, canvas size was 980*347.

FishIEtank's canvas width seems fixed to 980 when it fits to screen on flame. From it, the default scale(1.5 on flame) seems not related to FishIEtank case.
(Assignee)

Comment 78

4 years ago
attachment 8488094 [details] [diff] [review] is not a regression from b2g-v1.4. From Comment 76, game screen canvas seems normally created within screen display size.
(Assignee)

Comment 79

4 years ago
width=980 seems to come from the following.

> static const int32_t  kViewportDefaultScreenWidth = 980;
  http://dxr.mozilla.org/mozilla-central/source/content/base/public/nsViewportInfo.h#19

But somehow, its value seems to be used in FishIEtank case. Though, from Bug 999841 Comment 3, FishIEtank has the following viewport tag.

> <meta name="viewport" content="width=480, initial-scale=1, maximum-scale=1, user-scalable=no"/>
(Assignee)

Comment 80

4 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #79)
> width=980 seems to come from the following.
> 
> > static const int32_t  kViewportDefaultScreenWidth = 980;
>  
> http://dxr.mozilla.org/mozilla-central/source/content/base/public/
> nsViewportInfo.h#19
> 
> But somehow, its value seems to be used in FishIEtank case. Though, from Bug
> 999841 Comment 3, FishIEtank has the following viewport tag.

It seems a problem of Bug 1059483.
(Assignee)

Comment 81

4 years ago
When canvas element is created without viewport tag, the canvas does not fill the screen. From comment 66, at first it is because of default scaling(1.5x on Flame). But it seems to be caused by "kViewportDefaultScreenWidth = 980".

The following link is one example.
  http://people.mozilla.org/~sikeda/simple_canvas.html
(Assignee)

Comment 82

4 years ago
Created attachment 8488332 [details]
Screenshot of Comment 81's simple_canvas.html on flame.

Canvas' width is almost 1/2 of display. From it, "kViewportDefaultScreenWidth = 980" seems valid.
https://hg.mozilla.org/mozilla-central/rev/27ce050ada04
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
(Assignee)

Comment 85

4 years ago
Comment on attachment 8488094 [details] [diff] [review]
patch - Partially disable SkiaGL on Low total system memory

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 999841
User impact if declined: some application might be killed more because of oom.
Testing completed: locally tested
Risk to taking this patch (and alternatives if risky): low.
String or UUID changes made by this patch:
Attachment #8488094 - Flags: approval-mozilla-b2g32?
Attachment #8488094 - Flags: approval-gaia-v2.1?
Attachment #8488094 - Flags: approval-gaia-v2.0?
(Assignee)

Updated

4 years ago
Attachment #8488094 - Flags: approval-gaia-v2.1?
Attachment #8488094 - Flags: approval-gaia-v2.0?
Comment on attachment 8488094 [details] [diff] [review]
patch - Partially disable SkiaGL on Low total system memory

[Triage Comment]

Sotaro, I am approving this to land on aurora as well to fix the issue in 2.1

Rya, lets hope the patch applies cleanly:P else NI sotaro.
Attachment #8488094 - Flags: approval-mozilla-b2g32?
Attachment #8488094 - Flags: approval-mozilla-b2g32+
Attachment #8488094 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/475dda11aded
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/bb6a6337270c
status-b2g-v2.0: affected → fixed
status-b2g-v2.1: affected → fixed
status-b2g-v2.2: --- → fixed
status-firefox33: --- → wontfix
status-firefox34: --- → fixed
status-firefox35: --- → fixed
Target Milestone: --- → 2.1 S4 (12sep)
This issue is verified on Flame 2.2 and Flame 2.1:

Flame 2.2 KitKat Base (319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20141006040204
Gaia: 470826d13ae130a5c3d572d1029e595105485fb0
Gecko: e0d714f43edc
Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.1 KitKat Base (319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.1
BuildID: 20141006000205
Gaia: 778ebac47554e1c4b7e9a952d73e850f58123914
Gecko: c4a4b04c617c
Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

The app does not close out. Tapping the link displays "This Connection is Untrusted" page, and the user can access the page after selecting to proceed.
Status: RESOLVED → VERIFIED
QA Whiteboard: [2.0-signoff-need+] → [2.0-signoff-need+][QAnalyst-Triage?]
status-b2g-v2.1: fixed → verified
status-b2g-v2.2: fixed → verified
Flags: needinfo?(ktucker)
This issue is verified fixed on Flame 2.0.

Flame 2.0 KitKat Base (319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.0
BuildID: 20141006000202
Gaia: 092d2b7678774c8b0b06dca0e0a8119e9eafdec3
Gecko: 69ca61f7edf3
Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

The app does not close out. Tapping the link displays "This Connection is Untrusted" page, and the user can access the page after selecting to proceed.
status-b2g-v2.0: fixed → verified
Keywords: verifyme
QA Whiteboard: [2.0-signoff-need+][QAnalyst-Triage?] → [2.0-signoff-need+][QAnalyst-Triage+]
Flags: needinfo?(ktucker)

Comment 91

4 years ago
This issue has been verified successfully on Woodduck 2.0.
Reproducing rate: 0/5
See attachment: Verify_Woodduck_Heremap.MP4

build version:
Gaia-Rev        87b23fa81c3b59f2ba24b84f7d686f4160d4e7cb
Gecko-Rev       d049d4ef127844121c9cf14d2e8ca91fd9045fcb
Build-ID        20141124050313
Version         32.0
status-b2g-v2.0M: fixed → verified

Comment 92

4 years ago
Created attachment 8527406 [details]
Verify_Woodduck_Heremap.MP4

Comment 93

4 years ago
Remove "verifyme" from Keywords field because we have verified this bug on v2.0 and v2.0m build.
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.