Closed Bug 1604010 Opened 4 years ago Closed 4 years ago

Crash in [@ __memcpy_sse2_unaligned_erms | mozilla::image::BlendAnimationFilter<T>::DoResetToFirstRow]

Categories

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

Unspecified
Linux
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jseward, Unassigned)

Details

(Keywords: crash)

Crash Data

This bug is for crash report bp-9e6d5c0e-c80a-4713-9abb-547340191213.

This crash was reported 3 times in 2 different installations of the Linux
nightly 20191213094653.

Top 10 frames of crashing thread:

0 libc-2.30.so __memcpy_sse2_unaligned_erms 
1 libxul.so mozilla::image::BlendAnimationFilter<mozilla::image::SurfaceSink>::DoResetToFirstRow image/SurfaceFilters.h:702
2 libxul.so nsresult mozilla::image::BlendAnimationFilter<mozilla::image::SurfaceSink>::Configure<mozilla::image::SurfaceConfig> image/SurfaceFilters.h:682
3 libxul.so mozilla::Maybe<mozilla::image::SurfacePipe> mozilla::image::SurfacePipeFactory::MakePipe<mozilla::image::BlendAnimationConfig, mozilla::image::SurfaceConfig> image/SurfacePipeFactory.h:587
4 libxul.so mozilla::image::SurfacePipeFactory::CreateSurfacePipe image/SurfacePipeFactory.h:555
5 libxul.so mozilla::image::nsGIFDecoder2::BeginImageFrame image/decoders/nsGIFDecoder2.cpp:198
6 libxul.so mozilla::image::nsGIFDecoder2::FinishImageDescriptor image/decoders/nsGIFDecoder2.cpp:830
7 libxul.so mozilla::image::nsGIFDecoder2::DoDecode image/decoders/nsGIFDecoder2.cpp:426
8 libxul.so mozilla::image::Decoder::Decode image/Decoder.cpp:133
9 libxul.so mozilla::image::AnimationSurfaceProvider::Run image/AnimationSurfaceProvider.cpp:210

Flags: needinfo?(tnikkel)

I note all the reports have WebRender enabled according to the app notes. WebRender causes us to use shared memory for the image buffers; I think Linux will just give us the buffer handle, and if it fails to allocate when we actually write to it, we can get a SIGBUS error. Very annoying.

With that said, I have seen similar reports on Windows:

https://crash-stats.mozilla.com/report/index/09ce7fd6-d554-47d0-a4a7-5bd5f0191213#tab-details

Could we have an overread/write here for particular animated images? (Maybe we should try including/clearing the URL in crash reports on nightly when we start/stop decoding in Decoder::Decode.)

As an addition to comment 1: These previously would have been handled gracefully as part of the allocation process, and we would have just refused to decode the image in question instead of crashing the content process.

Priority: -- → P3

I don't think I have anything to add to whats already been said here.

Flags: needinfo?(tnikkel)

If this is caused by truncations or exhaustion of shared memory we should prioritize a fix for bug 1245239 so that the crashes are less obscure than this.

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.