861061 - OOM on news.nationalpost.com due to images

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Daniel Veditz [:dveditz]]

I'm running today's 2013-04-11 22.0a2 Aurora build on a Samsung Galaxy Tab 10.1 running Android 4.0.4

Aurora consistently crashes trying to load http://news.nationalpost.com/2013/04/10/graphic-north-koreas-conventional-arms/ It does not offer to send a crash stack for it, and according to about:crashes none has been sent.

Page loads OK on Desktop (Nightly). There's plugin content but I have plugins disabled according to the settings. It's a huge infographic so maybe just out of memory.

Comment 1

[Scoobidiver (away)]

Can you provide a logcat using for instance aLogcat?

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Yeah, this is a low-memory issue. I can reproduce on my Galaxy Tab running honeycomb. Log shows lots of low-mem output as the page is loading and then android kills fennec.

04-12 16:31:54.710 I/ActivityManager(  287): Process com.sec.android.provider.badge (pid 24455) has died.
04-12 16:31:54.710 I/ActivityManager(  287): Low Memory: No more background processes.
04-12 16:31:54.910 I/ActivityManager(  287): Process com.wssyncmldm (pid 24465) has died.
04-12 16:31:54.910 W/ActivityManager(  287): Scheduling restart of crashed service com.wssyncmldm/.DMService in 76438ms
04-12 16:31:54.910 I/ActivityManager(  287): Low Memory: No more background processes.
04-12 16:31:55.060 I/ActivityManager(  287): Process com.sec.android.socialhub:service (pid 24447) has died.
04-12 16:31:55.060 W/ActivityManager(  287): Scheduling restart of crashed service com.sec.android.socialhub/.service.SocialHubService in 86291ms
04-12 16:31:55.060 I/ActivityManager(  287): Low Memory: No more background processes.
04-12 16:31:55.910 I/ActivityManager(  287): Process com.google.process.gapps (pid 397) has died.
04-12 16:31:55.920 W/ActivityManager(  287): Scheduling restart of crashed service com.google.android.gsf/.gtalkservice.service.GTalkService in 95433ms
04-12 16:31:55.920 W/ActivityManager(  287): Scheduling restart of crashed service com.google.android.location/.NetworkLocationService in 105433ms
04-12 16:31:55.920 I/ActivityManager(  287): Low Memory: No more background processes.
04-12 16:31:56.050 D/LocationProviderProxy(  287): LocationProviderProxy.onServiceDisconnected ComponentInfo{com.google.android.location/com.google.android.location.NetworkLocationService}
04-12 16:31:56.060 D/GeocoderProxy(  287): onServiceDisconnected ComponentInfo{com.google.android.location/com.google.android.location.NetworkLocationService}
04-12 16:31:56.380 D/HierarchicalStateMachine(  287): handleMessage: E msg.what=83
04-12 16:31:56.380 D/HierarchicalStateMachine(  287): processMsg: ConnectedState
04-12 16:31:56.380 D/WifiStateMachine(  287): ConnectedState{ what=83 when=-3ms arg1=137 }
04-12 16:31:56.380 D/HierarchicalStateMachine(  287): handleMessage: X
04-12 16:31:58.110 I/ActivityManager(  287): Process com.android.providers.calendar (pid 5674) has died.
04-12 16:31:58.110 I/ActivityManager(  287): Low Memory: No more background processes.
04-12 16:31:58.560 I/ActivityManager(  287): Process org.mozilla.fennec (pid 23999) has died.
04-12 16:31:58.560 E/InputDispatcher(  287): channel '41cdfef8 org.mozilla.fennec/org.mozilla.fennec.App (server)' ~ Consumer closed input channel or an error occurred.  events=0x8
04-12 16:31:58.560 E/InputDispatcher(  287): channel '41cdfef8 org.mozilla.fennec/org.mozilla.fennec.App (server)' ~ Channel is unrecoverably broken and will be disposed!
04-12 16:31:58.560 I/WindowManager(  287): WIN DEATH: Window{419a4350 SurfaceView paused=false}
04-12 16:31:58.560 I/SurfaceFlinger(  223): id=1965 Removed SurfaceView idx=1 Map Size=3
04-12 16:31:58.570 I/WindowManager(  287): WIN DEATH: Window{41cdfef8 org.mozilla.fennec/org.mozilla.fennec.App paused=false}
04-12 16:31:58.580 I/SurfaceFlinger(  223): id=1966 Removed org.mozilla.fennec/org.mozilla.fennec.App idx=1 Map Size=2
04-12 16:31:58.580 I/SurfaceFlinger(  223): id=1965 Removed SurfaceView idx=-2 Map Size=2
04-12 16:31:58.580 I/SurfaceFlinger(  223): id=1966 Removed org.mozilla.fennec/org.mozilla.fennec.App idx=-2 Map Size=2
04-12 16:31:58.580 D/WindowManager(  287): Setting visibility of AppWindowToken{415e6128 token=ActivityRecord{415e6000 org.mozilla.fennec/.App}}: false
04-12 16:31:58.580 I/WindowManager(  287): WINDOW DIED Window{41cdfef8 org.mozilla.fennec/org.mozilla.fennec.App paused=false}
04-12 16:31:58.590 I/SurfaceFlinger(  223): id=1966 Removed org.mozilla.fennec/org.mozilla.fennec.App idx=-2 Map Size=2
04-12 16:31:58.590 I/SurfaceFlinger(  223): id=1965 Removed SurfaceView idx=-2 Map Size=2

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Attachment: About:memory dump from before the crash

Here's an about:memory dump from shortly before the crash (I triggered the dump manually as I saw the low-mem output in logcat, so it's not *right* before the crash, but reasonably close).

Comment 4

[Kartikaya Gupta (email:[e-mail])]

CC'ing njn for about:memory analysis expertise. It looks like mostly images and heap-unclassified - maybe this is a good candidate for DMD when it's working on Android.

Comment 5

[Nicholas Nethercote [inactive]]

Here's the relevant parts of kats' about:memory:

537,117,384 B (100.0%) -- explicit
├──316,964,800 B (59.01%) -- images
│  ├──316,931,936 B (59.01%) -- content
│  │  ├──316,931,936 B (59.01%) -- used
│  │  │  ├──265,368,320 B (49.41%) ── uncompressed-heap
│  │  │  ├───51,563,616 B (09.60%) ── raw
│  │  │  └────────────0 B (00.00%) ── uncompressed-nonheap
│  │  └────────────0 B (00.00%) ++ unused
│  └───────32,864 B (00.01%) ++ chrome
├──180,826,261 B (33.67%) ── heap-unclassified
├───15,530,988 B (02.89%) ++ js-non-window
├───12,242,144 B (02.28%) ++ window-objects
├────4,501,296 B (00.84%) ++ storage
├────2,233,896 B (00.42%) ++ startup-cache
├────1,840,540 B (00.34%) ── freetype
├──────876,672 B (00.16%) ── xpti-working-set
├──────466,624 B (00.09%) ++ gfx
├──────317,392 B (00.06%) ── atom-tables
├──────300,920 B (00.06%) ── xpconnect
├──────268,832 B (00.05%) ++ layout
├──────256,296 B (00.05%) ++ xpcom
├──────169,632 B (00.03%) ── preferences
├──────124,832 B (00.02%) ── script-namespace-manager
├───────76,352 B (00.01%) ── telemetry
├───────69,632 B (00.01%) ++ cycle-collector
├───────48,227 B (00.01%) ++ network
└────────2,048 B (00.00%) ── dom/event-listener-managers-hash

  549,160,172 B ── explicit
  274,896,552 B ── gfx-surface-image
    7,077,888 B ── gfx-textures
  524,780,232 B ── heap-allocated
  538,189,824 B ── heap-committed
  265,368,320 B ── images-content-used-uncompressed
  468,484,096 B ── resident
  452,374,528 B ── resident-unique
1,222,656,000 B ── vsize


First of all, I bet a decent chunk of the heap-unclassified is image related -- Cairo or drivers or something like that.  So this is basically an image-handling issue.

Second, "resident" is 468 MB.  kats, is that a reasonable number for OOM to happen?  Apparently the 10.1 has 1 GiB of RAM, but I guess a decent chunk of it is taken up by the OS.

I thought that the image.mem.max_decoded_image_kb pref was relevant.
From http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#1207:

1204 // The maximum amount of decoded image data we'll willingly keep around (we
1205 // might keep around more than this, but we'll try to get down to this value).
1206 // (This is intentionally on the high side; see bug 746055.)
1207 pref("image.mem.max_decoded_image_kb", 256000);

256000 KiB is 262,144,000 bytes, which is very close to your "uncompressed-heap" of 265,368,320 bytes.

But now I see that on mobile it defaults to 51200, not 256000.  Anyway, "too many images" is the basic problem.  CC'ing tn and jlebar and joe who know lots about image decoding.

Comment 6

[Nicholas Nethercote [inactive]]

Viewing that page (which indeed does have *many* *large* images) on desktop:

1,142.93 MB (100.0%) -- explicit
├────435.68 MB (38.12%) -- images
│    ├──435.10 MB (38.07%) -- content
│    │  ├──435.10 MB (38.07%) -- used
│    │  │  ├──383.14 MB (33.52%) ── uncompressed-heap
│    │  │  ├───51.96 MB (04.55%) ── raw
│    │  │  └────0.00 MB (00.00%) ── uncompressed-nonheap
│    │  └────0.00 MB (00.00%) ++ unused
│    └────0.58 MB (00.05%) ++ chrome

Comment 7

[Justin Lebar (not reading bugmail)]

Surely we have a bug we can dupe this to.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

(In reply to Nicholas Nethercote [:njn] from comment #5)
> Second, "resident" is 468 MB.  kats, is that a reasonable number for OOM to
> happen?  Apparently the 10.1 has 1 GiB of RAM, but I guess a decent chunk of
> it is taken up by the OS.

Seems reasonable, I think. The OS probably doesn't allow allocation over some threshold. Right now /proc/meminfo on the device shows MemFree as 358376 kB. Also I ran top to see how high the memory usage actually goes before Android kills it (in case I didn't grab the about:memory late enough). The last output from top is VSS=1218484K, RSS=500208K so it's pretty close.

Comment 9

[Timothy Nikkel (:tnikkel)]

I tried and failed to get this site to OOM. Maybe the sight changed?

Comment 10

[Nicholas Nethercote [inactive]]

I would guess that bug 689623 and/or bug 847223 fixed it.

Kats, can you test this again and/or mark it as fixed?  Thanks.

Comment 11

[Timothy Nikkel (:tnikkel)]

Bug 689623 had already landed when this bug was reported, and I would expect bug 847223 to only have an effect if the imagevisibility pref was turned on (and I just pushed that change to inbound an hour ago).

Comment 12

[Kartikaya Gupta (email:[e-mail])]

I tested loading this site again on my Galaxy Tab using the latest nightly, and it crashed during load as before. Then I tried loading the site using the inbound build from bug 862602 and it loaded beautifully! \o/

Marking fixed by bug 862602.

Comment 13

[Timothy Nikkel (:tnikkel)]

Weird, I have no problem loading the site in release, beta, aurora, or nightly on my Galaxy S2.

But glad it is now working.

Comment 14

[Kartikaya Gupta (email:[e-mail])]

(In reply to Timothy Nikkel (:tn) from comment #13)
> Weird, I have no problem loading the site in release, beta, aurora, or
> nightly on my Galaxy S2.

I think nationalpost.com delivers smaller images to phones than to tablets. The page definitely looks different on desktop if I use a phone vs tablet UA string.