1167253 - crash in OOM | large | NS_ABORT_OOM(unsigned int) | mozilla::css::ImageLoader::AddImage(mozilla::css::ImageValue*)

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[(Away)]

This bug was filed from the Socorro interface and is 
report bp-a7ad1915-97d7-4a46-b762-1c9042150515.
=============================================================

These are spurious OOMs that happen when the hash table tries to allocate size*count == 0x5a5a5a5a*0x5a5a5a5a bytes. In other words the hash table is dead.

Of the current trains, I only see this on 38 and 38.0.5.

NS_ABORT_OOM(unsigned int)
mozilla::css::ImageLoader::AddImage(mozilla::css::ImageValue*)
mozilla::css::ImageLoader::MaybeRegisterCSSImage(mozilla::css::ImageValue*)
TryToStartImageLoadOnValue 
TryToStartImageLoad

Comment 1

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

David, I "randomly" CC-d you on bug 1166036 as that one also seems to be a dead hash table, though otherwise unrelated.  I'm just wondering if we have some underlying problem (JS?) that's causing these things...

Comment 2

[(Away)]

(In reply to Milan Sreckovic [:milan] from comment #1)
> David, I "randomly" CC-d you on bug 1166036 as that one also seems to be a
> dead hash table, though otherwise unrelated.  I'm just wondering if we have
> some underlying problem (JS?) that's causing these things...

At first glance this one seems rather far removed from JS. UAF is unfortunately a big class of issue. It wouldn't surprise me if we had multiple independent issues in the source. (Unless you consider "use of C++" to be the common underlying issue - but that's a discussion for another day!)

Comment 3

[Andrew McCreight [:mccr8]]

I looked at a few of these stacks, and they all seem to have a bunch of layout flush stuff in there. I wouldn't be too surprised if we have some kind of outstanding issue there.  Some of the symptoms sound similar to bug 1164766, which is also 38-only.

Comment 4

[Mats Palmgren (inactive)]

40.0a2: bp-22c9999e-99b0-4603-a8fb-3a0bb2150523
41.0a1: bp-c7477799-b709-41ec-8b68-eb9cd2150523
both have "OOM Allocation Size: 3730231112"
0x5a5a5a5a * 0x34B4B4B4 = 3730231112

0x34B4B4B4 >> 1 = 0x1A5A5A5A which is just 1 bit away from 0x5a5a5a5a.

I doubt this is a coincidence so I think this bug also occurs in later
versions.

Comment 5

[Mats Palmgren (inactive)]

This is probably related: bp-78f720d3-74a0-4e11-9a53-0a0662150525
It's an UAF write (I suspect) with basically the same stack.

Comment 6

[Mats Palmgren (inactive)]

I think I've found the signature for the v40/41 crashes.
They are reported under "OOM | unknown ..." for some reason.

Comment 7

[Seth Fowler [:seth] [:s2h]]

I can't look at this in the near term because issues affecting B2G 2.2 are taking priority. I'll circle around to this when I have time...

Comment 8

[Andrew McCreight [:mccr8]]

If you have some time, it would be good if you could look at this.

Comment 9

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

Possible red herring, but - one of the crashes (https://crash-stats.mozilla.com/report/index/732d4040-4d24-47a1-b8fd-cfe532150709) starts reporting trouble in graphics with DrawTargetD2D1::OptimizeSourceSurface failing to create a bitmap sized  27 x 12123 (which is reasonable, the height is beyond what D2D can handle.)

Comment 10

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

Forgot to mention - the (possible) red herring message above reports the failure is due to "invalid argument', which, again, makes sense.

Comment 11

[Timothy Nikkel (:tnikkel)]

I seem to remember another bug with d2d and very large sized surfaces before.

Comment 12

[Andrew McCreight [:mccr8]]

I don't see any crashes with this signature on versions newer than 40, so maybe it is fixed in 41?

Comment 13

[(Away)]

(In reply to Andrew McCreight [:mccr8] from comment #12)
> I don't see any crashes with this signature on versions newer than 40, so
> maybe it is fixed in 41?

Indeed. Not a single report on any version greater than 40 in the past month.