803125 - crash in imgStatusTrackerObserver::OnStartDecode

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Josh Matthews [:jdm]]

+++ 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

Comment 1

[Josh Matthews [:jdm]]

https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-10-18&signature=imgStatusTrackerObserver%3A%3AOnStartDecode%28%29&version=Firefox%3A19.0a1

Comment 2

[Scoobidiver (away)]

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

Comment 3

[Josh Matthews [:jdm]]

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.

Comment 4

[Josh Matthews [:jdm]]

Attachment: Notify status tracker when image request is destroyed.

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.

Comment 5

[Josh Matthews [:jdm]]

Attachment: Notify status tracker when image request is destroyed.

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

Comment 6

[Joe Drew (not getting mail)]

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?

Comment 7

[Josh Matthews [:jdm]]

Attachment: Notify status tracker when image request is destroyed.

Awkward.

Comment 8

[Josh Matthews [:jdm]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/278bf5deb265

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/278bf5deb265

Comment 10

[u279076]

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

Comment 11

[Josh Matthews [:jdm]]

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

Comment 12

[Ada [:adalucinet]]

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.