Open Bug 1802718 Opened 2 years ago Updated 2 years ago

Crash in [@ OOM | large | mozalloc_abort | moz_xmalloc | mozilla::image::nsAVIFDecoder::Decode ]

Categories

(Core :: Graphics: ImageLib, defect, P3)

defect

Tracking

()

Tracking Status
firefox107 --- affected
firefox108 --- affected
firefox109 --- affected

People

(Reporter: cpeterson, Unassigned)

References

Details

(Keywords: crash)

Crash Data

I see many Android crash reports about OOMs inmozilla::image::nsAVIFDecoder::Decode. Available Virtual Memory is usually about 1.7 GB and OOM Allocation Size is between 70 MB - 116 MB. There are also crash reports from Windows with a different crash signature: [@ OOM | large | mozalloc_abort | moz_xmalloc | mozilla::image::nsAVIFDecoder::Decode ]. There is just one crash report from Linux and none from macOS.

I suspect this is a new signature for an old crash. This bug's crash data graph appears to show a big regression in September, but I think that's when Socorro's stack traces started to include inlined functions. I filed bug 1802715 to generate more useful signatures that can continue after new[] and include mozilla::image::nsAVIFDecoder::Decode.

Crash report: https://crash-stats.mozilla.org/report/index/2221dbec-ebc9-4bbc-ba95-a4c110221121

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames of crashing thread:

0  libmozglue.so  MOZ_Crash  mfbt/Assertions.h:261
0  libmozglue.so  mozalloc_abort  memory/mozalloc/mozalloc_abort.cpp:35
1  libmozglue.so  mozalloc_handle_oom  memory/mozalloc/mozalloc_oom.cpp:51
2  libmozglue.so  moz_xmalloc  memory/mozalloc/mozalloc.cpp:54
3  libxul.so  operator new[]  memory/mozalloc/cxxalloc.h:42
3  libxul.so  mozilla::MakeUnique<unsigned char []>  mfbt/UniquePtr.h:612
3  libxul.so  mozilla::image::nsAVIFDecoder::Decode  image/decoders/nsAVIFDecoder.cpp:1589
3  libxul.so  mozilla::image::nsAVIFDecoder::DoDecode  image/decoders/nsAVIFDecoder.cpp:1167
4  libxul.so  mozilla::image::Decoder::Decode  image/Decoder.cpp:177
5  libxul.so  mozilla::image::DecodedSurfaceProvider::Run  image/DecodedSurfaceProvider.cpp:125
Crash Signature: [@ OOM | large | mozalloc_abort | moz_xmalloc | new[]] [@ OOM | large | mozalloc_abort | moz_xmalloc | mozilla::image::nsAVIFDecoder::Decode ] [@ mozalloc_abort | moz_xmalloc | mozilla::image::nsAVIFDecoder::Decode ] [@ OOM | large | mozalloc_abort | → [@ mozalloc_abort | moz_xmalloc | mozilla::image::nsAVIFDecoder::Decode ] [@ OOM | large | mozalloc_abort | moz_xmalloc | new[]] [@ OOM | large | mozalloc_abort | moz_xmalloc | mozilla::image::nsAVIFDecoder::Decode ] [@ OOM | large | mozalloc_abort |

Of the crashes on Windows all but three are on 102esr or 102 thunderbird. One is on 102 Firefox, two are on 105. Seems quite odd.

The line is allocating memory to store the decoded image. To get an idea of the size of image in that range, 4500 x 4500 x 4 (bytes) = 81mb. That's a pretty big image for desktop, nevermind mobile. Is there is site that is giving users avif's of that size commonly? Maybe the urls can shed some light?

Severity: -- → S3
Priority: -- → P3

(In reply to Timothy Nikkel (:tnikkel) from comment #1)

The line is allocating memory to store the decoded image. To get an idea of the size of image in that range, 4500 x 4500 x 4 (bytes) = 81mb. That's a pretty big image for desktop, nevermind mobile. Is there is site that is giving users avif's of that size commonly? Maybe the urls can shed some light?

Unfortunately, we don't have URLs for the Android OOMs, but here are some URLs from the desktop OOMs (64-bit Windows). I haven't tested these URLs on Android. The sites might serve different content to mobile users. None of these AVIFs are near the 4500 x 4500 size, so I don't know where the 70 MB - 116 MB allocation sizes are coming from.

Bug 1802715 has been fixed, so I'm adding what I believe the new crash signature will be.

[@ OOM | large | mozalloc_abort | moz_xmalloc | new[] | mozilla::image::nsAVIFDecoder::Decode]

Crash Signature: [@ mozalloc_abort | moz_xmalloc | mozilla::image::nsAVIFDecoder::Decode ] [@ OOM | large | mozalloc_abort | moz_xmalloc | new[]] [@ OOM | large | mozalloc_abort | moz_xmalloc | mozilla::image::nsAVIFDecoder::Decode ] [@ OOM | large | mozalloc_abort | m… → [@ mozalloc_abort | moz_xmalloc | mozilla::image::nsAVIFDecoder::Decode ] [@ OOM | large | mozalloc_abort | moz_xmalloc | new[]] [@ OOM | large | mozalloc_abort | moz_xmalloc | new[] | mozilla::image::nsAVIFDecoder::Decode] [@ OOM | large | mozalloc_ab…

There was a spike in this in Oct and Nov and then went away. A site was sending large avifs accidentally?

You need to log in before you can comment on or make changes to this bug.