1006088 - Cupcakes and Veggies oom crash on portrait mode

Status: RESOLVED INVALID

(Core :: Graphics: Canvas2D, defect, P1)

Description

[Sotaro Ikeda [:sotaro]]

"Cupcakes and Veggies" crashed when I started the app from e.me "Games" and a phone state is portrait mode.

*precondition
- phone is portrait state

*STR
-[1]Tap e.me "Games" icon on the homescreen
-[2]Select "Cupcakes and Veggies"
-[3]Keep the phone portrait state, even when the app ui asked to change to landcape state.

The app crashed after starting the app. When I set the phone to landscape mode, the app did not crash.

*Confirmed hardwware
- master flame, master nexus-5, master nexus-4.

Comment 1

[Sotaro Ikeda [:sotaro]]

The crash happened 100%.

Comment 2

[Sotaro Ikeda [:sotaro]]

Attachment: logcat of the crash on flame

Comment 3

[Jason Smith [:jsmith]]

Can we find out if the crash here is generating a crash report dialog message?

Comment 4

[Chris Kreinbring [:CKreinbring]]

Tested on the Flame 2.0 and did not see a crash report dialog message.

Comment 5

[Jason Smith [:jsmith]]

Can we get an about:memory report & dmesg log when this bug reproduces?

Comment 6

[Pi Wei Cheng [:piwei] (inactive)]

Attachment: dmesg log

Attaching the dmesg log.

I've been having issues with getting the about memory report on my station, I'll upload the report once I have it.

Comment 7

[Pi Wei Cheng [:piwei] (inactive)]

Attachment: about-memory-0.zip

Attaching about memory zip.

Running about memory on Flame with today's master build causes Firefox OS to crash (OS reboots and upon returning to OS, a crash report is generated and prompts user to send it). I'm not sure if the memory report is still useful under this circumstance but attaching it anyway.

Comment 8

[Jason Smith [:jsmith]]

Can we confirm this does not reproduce on 1.4?

Comment 9

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Jason Smith [:jsmith] from comment #8)
> Can we confirm this does not reproduce on 1.4?

Confirmed that issue is NOT reproducible on today's 1.4 Flame build with v10f base image.
Cupcake and Veggies does not crash when holding the phone vertically.

Comment 10

[Pi Wei Cheng [:piwei] (inactive)]

b2g-inbound Regression Window:

Last Working Environmental Variables:
Device: Flame MOZ
BuildID: 20140430053004
Gaia: adfe7c3fc8c8cf39bf14ab416ff531af1f3dd02f
Gecko: b5b912c44f82
Version: 32.0a1
Firmware Version: v10F

First Broken Environmental Variables:
Device: Flame MOZ
BuildID: 20140430083003
Gaia: cf285caa0c65244abae9fc99cc6f88765a8d8737
Gecko: cd8d210b9a94
Version: 32.0a1
Firmware Version: v10F

Last Working Gaia / First Broken Gecko: Issue DOES reproduce
Gaia: adfe7c3fc8c8cf39bf14ab416ff531af1f3dd02f
Gecko: cd8d210b9a94

Last Working Gecko / First Broken Gaia: Issue does NOT reproduce
Gaia: cf285caa0c65244abae9fc99cc6f88765a8d8737
Gecko: b5b912c44f82

b2g-inbound Pushlog:
http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=b5b912c44f82&tochange=cd8d210b9a94

Comment 11

[Jason Smith [:jsmith]]

I don't think the window is correct here - we're getting multiple changesets here for gecko. Could you please check this again?

We do know this is a gecko regression though.

Comment 12

[J Zimbrick]

mozilla-inbound Regression Window:

Last Working Environmental Variables: 
Device: Flame
BuildID: 20140429163002
Gaia: db3bcec51a361daddb7d3d4ba4d8a2a664b7b6aa
Gecko: de19c62cbc6b
Version: 32.0a1
Base Image: v10F

First Broken Environmental Variables:
Device: Flame
BuildID: 20140429193004
Gaia: db3bcec51a361daddb7d3d4ba4d8a2a664b7b6aa
Gecko: c0d658d3f739
Version: 32.0a1
Base Image: v10F

Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=de19c62cbc6b&tochange=c0d658d3f739

Comment 13

[Jason Smith [:jsmith]]

The window here clarifies this is definitely not a problem in the app, but rather a gecko problem.

bug 999841 looks suspicious here.

Ben - Did bug 999841 cause this?

Comment 14

[Jason Smith [:jsmith]]

QA Wanted - Can we try to reproduce this with the pref "gfx.canvas.max-size-for-skia-gl" set to 0?

Comment 15

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Jason Smith [:jsmith] from comment #14)
> QA Wanted - Can we try to reproduce this with the pref
> "gfx.canvas.max-size-for-skia-gl" set to 0?

The bug reproduces with the following line
user_pref("gfx.canvas.max-size-for-skia-gl", 0);
added to pref.js.

Tested on:
Device: Flame MOZ
BuildID: 20140515040207
Gaia: 3a1d67246a79e3632c3b3f2460a25291e7e2714c
Gecko: e4843f4f08a7
Version: 32.0a1
Firmware Version: v10F

Comment 16

[Ben Kelly [:bkelly, not reviewing]]

Thanks for the checking the pref.  I'm also going to look briefly in case the patch broke it in some other way.

Comment 17

[Ben Kelly [:bkelly, not reviewing]]

So setting the pref to 0 means "don't limit skia at all".  Maybe the issue is that we need to limit more, not less.  Trying to get my flame onto the given version to test this.

Comment 18

[Ben Kelly [:bkelly, not reviewing]]

So the version of Cupcakes vs Veggies I'm getting from marketplace has this in its manifest:

  "orientation":["landscape"]

This means they've removed the portrait mode warning completely.  I think this was a good move as its a better experience for the user.

Let me see if I can force portrait mode, though, in case this is just papering over a platform issue.

Comment 19

[Ben Kelly [:bkelly, not reviewing]]

And taking this for the time being while I investigate.

Comment 20

[Ben Kelly [:bkelly, not reviewing]]

So I hacked the manifest to allow portrait mode and then added some gecko instrumentation.  It appears the game is using skia for the reasonably sized canvas and avoiding skia on the huge canvases:

I/Gecko   (13096): ### ### CheckSizeForSkiaGL(2048x2048) returning false; 4194304 <= 1058400
I/Gecko   (13096): ### ### CheckSizeForSkiaGL(2048x2048) returning false; 4194304 <= 1058400
I/Gecko   (13096): ### ### CheckSizeForSkiaGL(960x536) returning true; 514560 <= 1058400

Before bug 999841, however, we were probably incorrectly blocking skia on the 960x536 canvas.

It seems whenever skia is used for this canvas, though, portrait mode causes the RSS for the device to climb infinitely until an OOM.  On my flame with 1GB I saw it hit 800+ MB.  This memory drops if you return to landscape mode before the OOM.

So I enabled profiling, entered portrait for a few seconds, then returned to landscape.  Here is the profile:

http://people.mozilla.org/~bgirard/cleopatra/#report=101594482556a192707a83337e5abca6e3661b8f

I believe the section with the ion compile markers is the when we are in portrait.

James, do you have any idea what the game is doing here?  Its unclear to me if the game is just doing evil things or if we have a platform problem.

Its also unclear to me if its worth debugging this since the game has disabled portrait mode in its manifest.

Comment 21

[Jason Smith [:jsmith]]

I'm confused here. The original STR implies that this does reproduce with landscape orientation locked as well, as Sotaro's STR implies that you just need to keep the phone itself in portrait to reproduce this when launching the app.

Can someone confirm this?

Comment 22

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Jason Smith [:jsmith] from comment #21)
> I'm confused here. The original STR implies that this does reproduce with
> landscape orientation locked as well, as Sotaro's STR implies that you just
> need to keep the phone itself in portrait to reproduce this when launching
> the app.
> 
> Can someone confirm this?

In comment 0 Sotaro indicates: "[3]Keep the phone portrait state, even when the app ui asked to change to landcape state."

The app only asks to change to landscape if the manifest is not locked to landscape.  So it appears to me the manifest has changed between comment 0 and today.

Comment 23

[Jason Smith [:jsmith]]

So this doesn't reproduce with the orientation locked to landscape then, right?

Comment 24

[Ben Kelly [:bkelly, not reviewing]]

From the profile it seems we are hitting SkAutoCachedTexture() a lot while in portrait mode here.  Perhaps we have some pathological cache behavior in play.

Comment 25

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Jason Smith [:jsmith] from comment #23)
> So this doesn't reproduce with the orientation locked to landscape then,
> right?

Correct.

Comment 26

[Pi Wei Cheng [:piwei] (inactive)]

You only need to go to 'Games' collection on Homescreen and open Cupcakes and Veggies there. I never had to go to marketplace to download the app.

Keep the phone in portrait mode, disregarding the warning that wants you in landscape, and the crash will occur within ~20 seconds.

The app will NOT crash in landscape, as originally stated.

Comment 27

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Pi Wei Cheng from comment #26)
> You only need to go to 'Games' collection on Homescreen and open Cupcakes
> and Veggies there. I never had to go to marketplace to download the app.

Yea, either the e.me collection does not serve a version with a manifest or that manifest has not been updated to match the one in marketplace.

Comment 28

[Ben Kelly [:bkelly, not reviewing]]

So this still seems like a problem and it would be great if we could get James or someone from gfx to look at the profile in comment 20.

Comment 29

[James Willcox (:snorp) ([e-mail]) (he/him)]

Weirdness. Can you look at about:memory output while running the game? I think there is a way to get that by sending a signal or something.

There is at least one known problem with Skia right now where it uses a ton of memory. Bug 990174.

Comment 30

[Ben Kelly [:bkelly, not reviewing]]

So the profile seems to have a large number of drawBitmapRect() calls and bug 990174 says that looping on drawBitmap is enough to trigger the memory increase there.  I'm going to go ahead and add a dependency for now.

I'll also try to get a memory report today, but it may be difficult as there is only a short window before an OOM occurs.

Comment 31

[Ben Kelly [:bkelly, not reviewing]]

So here is b2g-info during the memory bloat in portrait mode:

                          |      megabytes      |
           NAME  PID PPID CPU(s) NICE   USS   PSS   RSS VSIZE OOM_ADJ USER
            b2g  291    1   58.2    0  52.7  58.3  68.0 211.7       0 root
         (Nuwa)  919  291    1.2    0   2.3   5.5  13.4  53.3       0 root
        Browser 1171  919   76.7    1 202.8 466.4 735.3 810.7       2 u0_a1171
(Preallocated a 1404  919    0.7   18   4.8   8.6  17.3  61.3       1 u0_a1404

Interesting that the PSS is so large, but none of the other b2g processes have large PSS.  This suggests its shared resources with some other android process.

Here is the memory report, which was captures a bit before that b2g-info above.  Again, resident is large while explicit is small which suggests some external memory pages are being referenced somehow.

James, is this consistent with what you see in bug 990174?

33.65 MB (100.0%) -- explicit
├──12.62 MB (37.49%) -- images
│  ├──12.62 MB (37.49%) -- content/raster
│  │  ├──12.62 MB (37.49%) -- used
│  │  │  ├───8.25 MB (24.53%) ── raw
│  │  │  ├───4.36 MB (12.95%) ── uncompressed-nonheap
│  │  │  └───0.00 MB (00.01%) ── uncompressed-heap
│  │  └───0.00 MB (00.00%) ++ unused
│  └───0.00 MB (00.00%) ++ chrome/raster
├───6.67 MB (19.82%) ── heap-unclassified
├───5.09 MB (15.12%) -- js-non-window
│   ├──2.75 MB (08.17%) -- runtime
│   │  ├──0.81 MB (02.41%) ++ code
│   │  ├──0.60 MB (01.78%) ── script-data
│   │  ├──0.58 MB (01.73%) ── atoms-table
│   │  ├──0.42 MB (01.24%) ++ (9 tiny)
│   │  └──0.34 MB (01.00%) ++ script-sources
│   ├──2.26 MB (06.71%) -- zones
│   │  ├──1.13 MB (03.35%) -- zone(0xb3efac00)
│   │  │  ├──0.51 MB (01.51%) ++ compartment([System Principal])
│   │  │  ├──0.35 MB (01.05%) ++ compartment([System Principal], outOfProcessTabChildGlobal)
│   │  │  └──0.26 MB (00.79%) ++ (8 tiny)
│   │  ├──0.91 MB (02.71%) -- zone(0xb3f2f400)
│   │  │  ├──0.85 MB (02.53%) -- strings
│   │  │  │  ├──0.83 MB (02.47%) -- string(<non-notable strings>)
│   │  │  │  │  ├──0.46 MB (01.36%) ── malloc-heap
│   │  │  │  │  └──0.37 MB (01.11%) ── gc-heap
│   │  │  │  └──0.02 MB (00.06%) ++ string(length=8789, copies=1, ".fb_hidden{position:absolute;top:-10000px;z-index:10001}.fb_invisible{display:none}.fb_reset{background:none;border:0;border-spacing:0;color:#000;cursor:auto;direction:ltr;font-family:"lucida grande", tahoma, verdana, arial, sans-serif;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:1;margin:0;overflow:visible;padding:0;text-align:left;text-decoration:none;text-indent:0;text-shadow:none;text-transform:none;visibility:visible;white-space:normal;word-spacing:normal}.fb_reset>div{overflow:hidden}.fb_link img{border:none}/n.fb_dialog{background:rgba(82, 82, 82, .7);position:absolute;top:-10000px;z-index:10001}.fb_reset .fb_dialog_legacy{overflow:visible}.fb_dialog_advanced{padding:10px;-moz-border-radius:8px;-webkit-border-radius:8px;border-radius:8px}.fb_dialog_content{background:#fff;color:#333}.fb_dialog_close_icon{background:url(http://static.ak.fbcdn.net/rsrc.php/v2/yq/r/IE9JII6Z1Ys.png) no-repeat scroll 0 0 transparent;_background-image:url(http://s" (truncated))
│   │  │  └──0.06 MB (00.18%) ++ (4 tiny)
│   │  └──0.22 MB (00.65%) ++ zone(0xb3f32000)
│   └──0.08 MB (00.23%) ++ gc-heap
├───4.35 MB (12.91%) -- window-objects
│   ├──4.02 MB (11.93%) -- top(http://cupcakes-vs-veggies.tresensa.com/?dst=A0053, id=4)
│   │  ├──3.10 MB (09.22%) -- active
│   │  │  ├──2.32 MB (06.89%) -- window(http://cupcakes-vs-veggies.tresensa.com/?dst=A0053)
│   │  │  │  ├──1.90 MB (05.65%) -- js-compartment(http://cupcakes-vs-veggies.tresensa.com/?dst=A0053)
│   │  │  │  │  ├──0.88 MB (02.62%) -- objects
│   │  │  │  │  │  ├──0.67 MB (01.99%) ++ gc-heap
│   │  │  │  │  │  └──0.21 MB (00.63%) ++ (2 tiny)
│   │  │  │  │  ├──0.65 MB (01.92%) ++ shapes
│   │  │  │  │  └──0.37 MB (01.10%) ++ (5 tiny)
│   │  │  │  └──0.42 MB (01.25%) ++ (4 tiny)
│   │  │  ├──0.39 MB (01.16%) ++ window(http://static.ak.facebook.com/connect/xd_arbiter/dgdTycPTSRj.js?version=41#channel=f3618e9b4e808ce&origin=http%3A%2F%2Fcupcakes-vs-veggies.tresensa.com)
│   │  │  └──0.39 MB (01.16%) ++ window(https://s-static.ak.facebook.com/connect/xd_arbiter/dgdTycPTSRj.js?version=41#channel=f3618e9b4e808ce&origin=http%3A%2F%2Fcupcakes-vs-veggies.tresensa.com)
│   │  └──0.91 MB (02.71%) ++ js-zone(0xb34bf000)
│   └──0.33 MB (00.98%) ++ top(about:blank, id=1)
├───1.50 MB (04.44%) -- media
│   ├──1.26 MB (03.75%) ── libogg
│   └──0.23 MB (00.69%) ++ (4 tiny)
├───1.39 MB (04.12%) ++ (14 tiny)
├───1.20 MB (03.57%) -- heap-overhead
│   ├──1.13 MB (03.35%) ── waste
│   └──0.07 MB (00.22%) ++ (2 tiny)
└───0.85 MB (02.53%) ── xpti-working-set

Other Measurements

1.51 MB (100.0%) -- decommitted
└──1.51 MB (100.0%) -- js-non-window
   ├──1.51 MB (100.0%) ── gc-heap/decommitted-arenas
   └──0.00 MB (00.00%) ── runtime/gc/nursery-decommitted

42 (100.0%) -- event-counts
└──42 (100.0%) -- window-objects
   ├──39 (92.86%) -- top(http://cupcakes-vs-veggies.tresensa.com/?dst=A0053, id=4)/active
   │  ├──31 (73.81%) -- window(http://cupcakes-vs-veggies.tresensa.com/?dst=A0053)/dom
   │  │  ├──28 (66.67%) ── event-listeners
   │  │  └───3 (07.14%) ── event-targets
   │  ├───4 (09.52%) -- window(http://static.ak.facebook.com/connect/xd_arbiter/dgdTycPTSRj.js?version=41#channel=f3618e9b4e808ce&origin=http%3A%2F%2Fcupcakes-vs-veggies.tresensa.com)/dom
   │  │   ├──3 (07.14%) ── event-listeners
   │  │   └──1 (02.38%) ── event-targets
   │  └───4 (09.52%) -- window(https://s-static.ak.facebook.com/connect/xd_arbiter/dgdTycPTSRj.js?version=41#channel=f3618e9b4e808ce&origin=http%3A%2F%2Fcupcakes-vs-veggies.tresensa.com)/dom
   │      ├──3 (07.14%) ── event-listeners
   │      └──1 (02.38%) ── event-targets
   └───3 (07.14%) -- top(about:blank, id=1)/active/window(about:blank)/dom
       ├──2 (04.76%) ── event-listeners
       └──1 (02.38%) ── event-targets

8.47 MB (100.0%) -- js-main-runtime
├──3.45 MB (40.75%) -- compartments
│  ├──1.46 MB (17.25%) -- objects
│  │  ├──1.12 MB (13.24%) -- gc-heap
│  │  │  ├──0.55 MB (06.48%) ── function
│  │  │  ├──0.42 MB (04.97%) ── ordinary
│  │  │  └──0.15 MB (01.79%) ── dense-array
│  │  ├──0.34 MB (04.00%) -- malloc-heap
│  │  │  ├──0.28 MB (03.36%) ── slots
│  │  │  └──0.05 MB (00.65%) ++ (2 tiny)
│  │  └──0.00 MB (00.00%) ── non-heap/code/asm.js
│  ├──1.34 MB (15.82%) -- shapes
│  │  ├──0.75 MB (08.79%) -- gc-heap
│  │  │  ├──0.43 MB (05.07%) -- tree
│  │  │  │  ├──0.37 MB (04.33%) ── global-parented
│  │  │  │  └──0.06 MB (00.74%) ── non-global-parented
│  │  │  ├──0.24 MB (02.85%) ── base
│  │  │  └──0.07 MB (00.88%) ── dict
│  │  └──0.60 MB (07.03%) -- malloc-heap
│  │     ├──0.26 MB (03.08%) ── compartment-tables
│  │     ├──0.21 MB (02.48%) ── tree-tables
│  │     └──0.12 MB (01.46%) ++ (2 tiny)
│  ├──0.32 MB (03.81%) -- scripts
│  │  ├──0.25 MB (02.93%) ── gc-heap
│  │  └──0.07 MB (00.88%) ── malloc-heap/data
│  ├──0.18 MB (02.10%) ++ (3 tiny)
│  └──0.15 MB (01.76%) -- baseline
│     ├──0.10 MB (01.22%) ── fallback-stubs
│     └──0.05 MB (00.53%) ── data
├──2.75 MB (32.46%) ── runtime
├──2.19 MB (25.87%) -- zones
│  ├──0.95 MB (11.24%) -- strings
│  │  ├──0.54 MB (06.43%) ── malloc-heap
│  │  └──0.41 MB (04.82%) ── gc-heap
│  ├──0.58 MB (06.88%) ── unused-gc-things
│  ├──0.31 MB (03.69%) ── type-pool
│  ├──0.14 MB (01.62%) ── type-objects/gc-heap
│  ├──0.13 MB (01.53%) -- lazy-scripts
│  │  ├──0.11 MB (01.29%) ── gc-heap
│  │  └──0.02 MB (00.25%) ── malloc-heap
│  └──0.08 MB (00.91%) ++ (4 tiny)
└──0.08 MB (00.92%) ++ gc-heap

11 (100.0%) -- js-main-runtime-compartments
├───6 (54.55%) -- system
│   ├──2 (18.18%) ── [System Principal], outOfProcessTabChildGlobal [2]
│   ├──1 (09.09%) ── [System Principal]
│   ├──1 (09.09%) ── [System Principal], XPConnect Junk Compartment
│   ├──1 (09.09%) ── atoms
│   └──1 (09.09%) ── null-principal
└───5 (45.45%) -- user
    ├──1 (09.09%) ── about:blank
    ├──1 (09.09%) ── http://cupcakes-vs-veggies.tresensa.com/?dst=A0053
    ├──1 (09.09%) ── http://static.ak.facebook.com/connect/xd_arbiter/dgdTycPTSRj.js?version=41#channel=f3618e9b4e808ce&origin=http%3A%2F%2Fcupcakes-vs-veggies.tresensa.com
    ├──1 (09.09%) ── https://s-static.ak.facebook.com/connect/xd_arbiter/dgdTycPTSRj.js?version=41#channel=f3618e9b4e808ce&origin=http%3A%2F%2Fcupcakes-vs-veggies.tresensa.com
    └──1 (09.09%) ── moz-nullprincipal:{d670b089-09f9-4d2b-8d14-29c40148a0f6}

3.49 MB (100.0%) -- js-main-runtime-gc-heap-committed
├──2.91 MB (83.29%) -- used
│  ├──2.80 MB (80.23%) ── gc-things
│  ├──0.08 MB (02.24%) ── chunk-admin
│  └──0.03 MB (00.82%) ── arena-admin
└──0.58 MB (16.71%) -- unused
   ├──0.58 MB (16.71%) ── gc-things
   └──0.00 MB (00.00%) ++ (2 tiny)

4 (100.0%) -- message-manager
└──4 (100.0%) -- referent/child-process-manager
   ├──4 (100.0%) ── strong
   └──0 (00.00%) ++ weak

245 (100.0%) -- observer-service
└──245 (100.0%) -- referent
   ├──164 (66.94%) ── strong
   └───81 (33.06%) -- weak
       ├──79 (32.24%) ── alive
       └───2 (00.82%) ── dead

344 (100.0%) -- preference-service
└──344 (100.0%) -- referent
   ├──315 (91.57%) ── strong
   └───29 (08.43%) -- weak
       ├──29 (08.43%) ── alive
       └───0 (00.00%) ── dead

0.96 MB (100.0%) -- window-objects
├──0.73 MB (75.58%) -- layout
│  ├──0.50 MB (51.97%) ── style-sets
│  ├──0.16 MB (16.74%) ── pres-shell
│  ├──0.04 MB (03.97%) ── rule-nodes
│  ├──0.02 MB (01.65%) ++ (4 tiny)
│  └──0.01 MB (01.25%) ── style-contexts
├──0.17 MB (17.44%) -- dom
│  ├──0.06 MB (06.68%) ── text-nodes
│  ├──0.04 MB (04.54%) ── element-nodes
│  ├──0.04 MB (04.34%) ── orphan-nodes
│  ├──0.02 MB (01.75%) ── other
│  └──0.00 MB (00.13%) ++ (3 tiny)
├──0.07 MB (06.85%) ── style-sheets
└──0.00 MB (00.13%) ── property-tables

  1.96 MB ── canvas-2d-pixels
  0.00 MB ── gfx-surface-image
  0.00 MB ── gfx-textures
        0 ── ghost-windows
  0.00 MB ── gralloc
 23.79 MB ── heap-allocated
 24.99 MB ── heap-committed
    5.04% ── heap-overhead-ratio
  0.00 MB ── imagelib-surface-cache
  0.28 MB ── js-main-runtime-temporary-peak
        2 ── page-faults-hard
2,589,390 ── page-faults-soft
346.98 MB ── resident
 64.54 MB ── resident-unique
  0.01 MB ── shmem-allocated
  0.01 MB ── shmem-mapped
419.03 MB ── vsize

End of Browser (pid 1171)

Comment 32

[Ben Kelly [:bkelly, not reviewing]]

This part of the system report (not copied above) is probably most interesting:

911.67 MB (100.0%) -- mem
├──414.73 MB (45.49%) -- processes
│  ├──282.58 MB (31.00%) -- process(/system/b2g/plugin-container, pid=1171)
│  │  ├──251.16 MB (27.55%) -- other-files
│  │  │  ├──246.69 MB (27.06%) ── kgsl-3d0/[rw-s] [491]

Google suggests kgsl is part of the adreno gl driver/library.

Comment 33

[James Willcox (:snorp) ([e-mail]) (he/him)]

Yup, this is consistent with the kind of thing I saw in bug 990174. Some kind of GPU resource leak (maybe programs?)

Comment 34

[Andreas Gal :gal]

Can we track WebGL resources to detect leaks?

Comment 35

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Andreas Gal :gal from comment #34)
> Can we track WebGL resources to detect leaks?

Well an actual leak would have to be caused by the driver and we have no way of tracking that (AFAIK). We do have a way of tracking unnecessary retention of stuff via tools like apitrace. When I tried that on bug 990174, it didn't show anything growing unbounded.

Ben (or whoever), can you try reproducing this bug on desktop? You probably won't OOM, but you may be able to reproduce the crazy memory usage. SkiaGL canvas mostly works fine on Mac/Linux if you set the various gfx.canvas prefs.

Comment 36

[Ben Kelly [:bkelly, not reviewing]]

I am boarding a flight shortly, so probably won't have time to look at this.

Note, we do in theory have a way to run apitrace on the device.  I just tried to build it but I don't have the right ndk.  That might be an easier path to fix vs figuring out how to force the mobile game to trigger the problem on desktop.

Comment 37

[Nicholas Nethercote [inactive]]

> Can we track WebGL resources to detect leaks?

WebGL drivers is one of the biggest remaining holes in the memory reporting infrastructure, unfortunately. DMD can get info about WebGL allocations, but about:memory can't.

Comment 38

[Mason Chang [Inactive] [:mchang]]

Triage: From comment 36 and 37, it looks like this might be a WebGL issue. Milan, can you please find an owner for this? Thanks!

Comment 39

[Milan Sreckovic [:milan] (needinfo for best results)]

I don't think this is a WebGL game, but yes, we'll get to it for 2.0

Comment 40

[Ivan Tsay (:ITsay)]

Hi Jeff,

Mind if you can share the status for this bug. This bug has not been updated for two weeks. Thank you very much.

Comment 41

[Milan Sreckovic [:milan] (needinfo for best results)]

I'm talking to Jeff off line on this.

Comment 42

[Kelsey Gilbert [:jgilbert]]

Yep, this sounds like SkiaGL not WebGL.

Comment 43

[George Wright (:gw280) (needinfo me!)]

Well the good news is, I can reproduce this.

The bad news is, I can't reproduce it when gdb is attached.

Still investigating...

Comment 44

[George Wright (:gw280) (needinfo me!)]

I was a bit overzealous in thinking that I'd reproduced the bug. Turns out it was just slowing down my device a LOT which I'd thought was a crash, but actually wasn't.

I've been talking with Sotaro about this and it seems that all the usecases where this bug could be reproduced have gone (the CvV app was only visible on the horizontal homescreen e.me, which has been removed in latest 2.0/master; the CvV from marketplace doesn't exhibit the issue and I think enforces landscape mode now).

Sotaro thinks this is probably INVALID as it's unreproducible under normal circumstances, but I think that Skia should definitely not be OOMing and causing a crash, so I'm going to leave it open for now and check out an older version of gaia that allows me to reproduce it. Depending on the issue, I may close this as INVALID and open a new bug that covers the skia issue directly.

Does that sound reasonable Jason?

Comment 45

[Jason Smith [:jsmith]]

yeah - let's close this. The app developer I think made a fix here to pause the app when it's portrait, so we no longer can reproduce this bug.

Comment 46

[George Wright (:gw280) (needinfo me!)]

So hacking the manifest in the same way as Ben did in comment 20 didn't yield any crash on my device (hamachi). I think the resolution of invalid is correct, at least until we can find a new testcase.