+++ This bug was initially created as a clone of Bug #801701 +++ Similar to bug 801701, but I suspect a different cause. 0 @0x610076 1 xul.dll imgStatusTrackerObserver::OnStartDecode image/src/imgStatusTracker.cpp:63 2 xul.dll mozilla::image::Decoder::Init image/src/Decoder.cpp:48 3 xul.dll mozilla::image::RasterImage::InitDecoder image/src/RasterImage.cpp:2386 4 xul.dll mozilla::image::RasterImage::RequestDecodeCore image/src/RasterImage.cpp:2596 5 xul.dll mozilla::image::RasterImage::RequestDecode image/src/RasterImage.cpp:2529 6 xul.dll imgRequest::RequestDecode image/src/imgRequest.cpp:452 7 xul.dll imgRequestProxy::RequestDecode image/src/imgRequestProxy.cpp:320 8 xul.dll LockEnumerator content/base/src/nsDocument.cpp:8560 9 xul.dll nsBaseHashtable<nsPtrHashKey<imgIRequest>,unsigned int,unsigned int>::s_EnumRead obj-firefox/dist/include/nsBaseHashtable.h:400 10 xul.dll PL_DHashTableEnumerate obj-firefox/xpcom/build/pldhash.cpp:716 11 xul.dll nsDocument::SetImageLockingState content/base/src/nsDocument.cpp:8588 12 xul.dll PresShell::SetIsActive layout/base/nsPresShell.cpp:8950 13 xul.dll nsDocShell::SetIsActive docshell/base/nsDocShell.cpp:5185 14 xul.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:70 15 xul.dll XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:2433 16 xul.dll XPCWrappedNative::SetAttribute js/xpconnect/src/xpcprivate.h:2851 17 xul.dll XPC_WN_GetterSetter js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1528 18 mozjs.dll js::InvokeKernel js/src/jsinterp.cpp:367 19 mozjs.dll js::Invoke js/src/jsinterp.cpp:412

With combined signatures, it's #8 top crasher over the last 3 days.

Ok, the problem here is that we have RasterImages (and therefore and imgStatusTracker and imgStatusTrackerObserver) which are no longer tied to the lifetime of the original imgRequest, since the status tracker merely holds a weak pointer. In particular, if an image is copied to the clipboard and then the original request's references are released (ie. all proxies die, etc.), the imgRequest is destroyed, and the tracker's weak pointer is now pointing at freed memory.

So I was able to reproduce this once on Linux by chance, but I was unable to find a series of steps that would reproduce this reliably, let alone inside a test harness.

Actually the runnable pointer can stay, since it keeps the request alive.

Comment on attachment 681957 [details] [diff] [review] Notify status tracker when image request is destroyed. Review of attachment 681957 [details] [diff] [review]: ----------------------------------------------------------------- ::: image/src/imgRequest.cpp @@ +108,5 @@ > > imgRequest::~imgRequest() > { > + // The status tracker can outlive this request, and needs to know it's dying. > + //GetStatusTracker().ClearRequest(); Er?

Awkward.

Is there a testcases/steps QA can use to verify this is fixed?

No. I was never able to find a consistent way to reproduce the problem.

Marking as verified in Firefox 19 based on this crash reports: https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A19.0b3&query_search=signature&query_type=contains&query=imgStatusTrackerObserver%3A%3AOnStartDecode%28%29&reason_type=contains&date=01%2F29%2F2013%2015%3A21%3A41&range_value=4&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=imgStatusTrackerObserver%3A%3AOnStartDecode%28%29#reports https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A19.0b3&query_search=signature&query_type=contains&query=imgRequestProxy%3A%3ABlockOnload%28%29&reason_type=contains&date=01%2F29%2F2013%2015%3A22%3A01&range_value=4&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=imgRequestProxy%3A%3ABlockOnload%28%29#reports I consider that this new crashes are not related with this bug. If anyone has a different opinion, please feel free to reopen the bug.