This bug was filed from the Socorro interface and is report bp-5bed5a20-f0b4-4ca2-8c48-6b2b52150922. ============================================================= Steps to reproduce: --> Load http://www.oktoberfest.de/de --> Scroll down to bottom of the page ---> Crash

Let's start with imagelib in case we're passing Skia the bad data. Is this canvas, or is somebody using a non-default content setting?

Doesn't look like it's canvas, just regular image decoding. Maybe mRowBuffer is null in Downscaler::CommitRow()? Though the way mRowBuffer is allocated looks confusing to me; it tries to deal with allocation failures, but only uses infallible allocations as far as I can tell. Seth will know more about this.

This may have been me.

I can't reproduce this? Can you Markus?

I can't reproduce it. I was only looking at the crash report.

I can confirm this on Win7 (64bit) https://crash-stats.mozilla.com/report/index/c680cb9d-cb43-453a-842e-8637a2150923 Graphics Adapter Description NVIDIA GeForce GTX 750 Ti Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM 2048 Asynchronous Pan/Zoom none Device ID 0x1380 Direct2D Enabled true DirectWrite Enabled true (6.2.9200.17461) Driver Date 9-13-2015 Driver Version 10.18.13.5598 GPU #2 Active false GPU Accelerated Windows 1/1 Direct3D 11 (OMTC) Subsys ID 36811458 Supports Hardware H264 Decoding Yes Vendor ID 0x10de WebGL Renderer Google Inc. -- ANGLE (NVIDIA GeForce GTX 750 Ti Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote true AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0

seems on debug builds this is : Assertion failure: mTargetSize.height <= aOriginalSize.height (Created a downsca ler, but height is larger), at c:/Users/mozilla/debug-builds/mozilla-central/ima ge/Downscaler.cpp:70 #01: mozilla::image::nsGIFDecoder2::BeginImageFrame (c:\users\mozilla\debug-buil ds\mozilla-central\image\decoders\nsgifdecoder2.cpp:283) #02: mozilla::image::nsGIFDecoder2::WriteInternal (c:\users\mozilla\debug-builds \mozilla-central\image\decoders\nsgifdecoder2.cpp:1106) #03: mozilla::image::Decoder::Write (c:\users\mozilla\debug-builds\mozilla-centr al\image\decoder.cpp:186) #04: mozilla::image::Decoder::Decode (c:\users\mozilla\debug-builds\mozilla-cent ral\image\decoder.cpp:128) #05: mozilla::image::DecodePool::Decode (c:\users\mozilla\debug-builds\mozilla-c entral\image\decodepool.cpp:455) #06: mozilla::image::DecodePoolWorker::Run (c:\users\mozilla\debug-builds\mozill a-central\image\decodepool.cpp:292) #07: nsThread::ProcessNextEvent (c:\users\mozilla\debug-builds\mozilla-central\x pcom\threads\nsthread.cpp:960) #08: NS_ProcessNextEvent (c:\users\mozilla\debug-builds\mozilla-central\xpcom\gl ue\nsthreadutils.cpp:277) #09: mozilla::ipc::MessagePumpForNonMainThreads::Run (c:\users\mozilla\debug-bui lds\mozilla-central\ipc\glue\messagepump.cpp:326) #10: MessageLoop::RunInternal (c:\users\mozilla\debug-builds\mozilla-central\ipc \chromium\src\base\message_loop.cc:234) #11: MessageLoop::RunHandler (c:\users\mozilla\debug-builds\mozilla-central\ipc\ chromium\src\base\message_loop.cc:228) #12: MessageLoop::Run (c:\users\mozilla\debug-builds\mozilla-central\ipc\chromiu m\src\base\message_loop.cc:202) #13: nsThread::ThreadFunc (c:\users\mozilla\debug-builds\mozilla-central\xpcom\t hreads\nsthread.cpp:384) #14: _PR_NativeRunThread (c:\users\mozilla\debug-builds\mozilla-central\nsprpub\ pr\src\threads\combined\pruthr.c:397) #15: pr_root (c:\users\mozilla\debug-builds\mozilla-central\nsprpub\pr\src\md\wi ndows\w95thred.c:90) #16: _get_flsindex[MSVCR120 +0x2c01d] #17: _get_flsindex[MSVCR120 +0x2c001] #18: BaseThreadInitThunk[kernel32 +0x4ee1c] #19: RtlInitializeExceptionChain[ntdll +0x637eb] #20: RtlInitializeExceptionChain[ntdll +0x637be]

Possible dupe of bug 1207958. Really wishing I could figure out how to reproduce these. Given that everyone who can is on Windows, I'm suspicious that they may have a weird dev pixel ratio that we're rounding badly.

Is this connected to bug 1206744? The signatures look very similar.

I'm going to call this a duplicate of bug 1206744, which is fixed. No crashes of this signature are appearing in the most recent nightlies.