Crash in [@ __memcpy_sse2_unaligned_erms | mozilla::image::BlendAnimationFilter<T>::DoResetToFirstRow]
Categories
(Core :: Graphics: ImageLib, defect, P3)
Tracking
()
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
Comment 1•4 years ago
|
||
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.)
Comment 2•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 3•4 years ago
|
||
I don't think I have anything to add to whats already been said here.
Comment 4•4 years ago
|
||
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.
Comment 5•4 years ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•