Various imagelib related crashes

It's #2 top browser crasher in the first days of 19.0 on Linux.

Many crash reports have Mesa.

Signature imgRequestProxy::UnblockOnload() More Reports Search
UUID 83185214-0cd8-4872-afd0-7ab2e2130222
Date Processed 2013-02-22 09:10:21
Uptime 231
Last Crash more than 3 months before submission
Install Age 1.8 days since version was first installed.
Install Time 2013-02-20 13:09:21
Product Firefox
Version 19.0
Build ID 20130218103552
Release Channel release
OS Linux
OS Version 0.0.0 Linux 3.0.0-31-generic #48-Ubuntu SMP Mon Feb 4 13:25:59 UTC 2013 i686
Build Architecture x86
Build Architecture Info AuthenticAM family 15 model 107 stepping 2
Crash Reason SIGSEGV
Crash Address 0x1c24549b
App Notes
OpenGL: X.Org R300 Project -- Gallium 0.4 on ATI RS740 -- 2.1 Mesa 7.11 -- texture_from_pixmap
Processor Notes sp-processor05.phx1.mozilla.com_14839:2008; exploitablity tool: ERROR: unable to analyze dump
EMCheckCompatibility True

Frame Module Signature Source
0 libxul.so imgRequestProxy::UnblockOnload imgRequestProxy.cpp:818
1 libxul.so imgStatusTracker::MaybeUnblockOnload imgStatusTracker.cpp:766
2 libxul.so imgStatusTrackerObserver::OnStopFrame imgStatusTracker.cpp:133
3 libxul.so mozilla::image::Decoder::PostFrameStop Decoder.cpp:244
4 libxul.so mozilla::image::nsPNGDecoder::end_callback nsPNGDecoder.cpp:858
5 libxul.so MOZ_PNG_push_have_end pngpread.c:1453
6 libxul.so MOZ_PNG_push_read_chunk pngpread.c:358
7 libxul.so MOZ_PNG_process_data pngpread.c:40
8 libxul.so mozilla::image::nsPNGDecoder::WriteInternal nsPNGDecoder.cpp:349
9 libxul.so mozilla::image::Decoder::Write Decoder.cpp:79
10 libxul.so mozilla::image::RasterImage::WriteToDecoder RasterImage.cpp:2648
11 libxul.so mozilla::image::RasterImage::DecodeSomeData RasterImage.cpp:3167
12 libxul.so mozilla::image::RasterImage::DecodeWorker::DecodeSomeOfImage RasterImage.cpp:3478
13 libxul.so mozilla::image::RasterImage::DecodeWorker::Run RasterImage.cpp:3403
14 libxul.so nsThread::ProcessNextEvent nsThread.cpp:627
15 libxul.so NS_ProcessNextEvent_P nsThreadUtils.cpp:238
16 libxul.so mozilla::ipc::MessagePump::Run MessagePump.cpp:82
17 libxul.so MessageLoop::RunInternal message_loop.cc:215
18 libxul.so MessageLoop::Run message_loop.cc:208
19 libxul.so nsBaseAppShell::Run nsBaseAppShell.cpp:163
20 libxul.so nsAppStartup::Run nsAppStartup.cpp:290
21 libxul.so XREMain::XRE_mainRun nsAppRunner.cpp:3823
22 libxul.so XREMain::XRE_main nsAppRunner.cpp:3890
23 libxul.so XRE_main nsAppRunner.cpp:4084
24 firefox main nsBrowserApp.cpp:174

More reports at:
https://crash-stats.mozilla.com/report/list?signature=imgRequestProxy%3A%3AUnblockOnload%28%29

More reports also at:
https://crash-stats.mozilla.com/report/list?signature=nsQueryInterface%3A%3Aoperator%28%29%28nsID+const%26%2C+void**%29+const

Some guidance for QA:

" upgrade on ubuntu 12/04 to ff 19.0 reopening one pined tab (gmail) + 1 twitter tab + 3 other tabs, get a freeze."
"I was using a gesture plugin to open multiple tabs from links, and it shut down."

Seems to happen when opening tabs? KaiRo should be able to help with add-on correlations, which I suspect will be to blame if we didn't reproduce in our own pre-release testing.

  imgRequestProxy::UnblockOnload()|SIGSEGV (18 crashes)
    100% (18/18) vs. 61% (468/766) <email address hidden>
     28% (5/18) vs. 11% (84/766) <email address hidden> (Firebug, https://addons.mozilla.org/addon/1843)
     94% (17/18) vs. 81% (623/766) <email address hidden>

(In reply to Robert Kaiser (:<email address hidden>) from comment #3)
> imgRequestProxy::UnblockOnload()|SIGSEGV (18 crashes)
> 100% (18/18) vs. 61% (468/766) <email address hidden>
> 28% (5/18) vs. 11% (84/766) <email address hidden> (Firebug,
> https://addons.mozilla.org/addon/1843)
> 94% (17/18) vs. 81% (623/766) <email address hidden>

Sounds like this may just be through normal usage in that case.

Sigh, this is almost certainly my addon which causes this :(

Well, my suspicion is that it triggers rather than causes the crash (unless it's a binary one that is mucking with imagelib stuff). If you can reproduce it, that would be extremely helpful.

It's both - binary and using imagelib.

I haven't been able to reproduce it at all. But IIUC the trace suggests that the observer has been freed already, and when I checked if this could happen in our addon I realized that we're calling imgIRequest::Cancel() when releasing our only reference to the imgINotificationObserver. I guess this is likely to cause these types of crashes? I don't know why this hasn't shown up before, seeing as it's been like it for nearly 2 years :/

I wish we could catch these issues sooner. We have our (Ubuntu) crash reports appear in Socorro for release builds, but the crash reports from the beta builds we provide aren't exposed in the UI (presumably there is some server side magic to map a build ID to a particular beta milestone, eg 20.0b1)

Eg, https://crash-stats.mozilla.com/topcrasher/byos/Firefox/20.0b1/Linux/7/browser shows crashes for the Mozilla builds, but you need to manually hunt for crashes in "20.0" to find ours:

https://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A20.0&platform=linux&range_value=1&range_unit=weeks&date=02%2F27%2F2013+17%3A49%3A10&query_search=signature&query_type=contains&query=&reason=&build_id=&process_type=any&hang_type=any&do_query=1

Is there anything we can do to fix this?

You may want CancelAndForgetObserver, but I can never remember when one is more appropriate than the other. Maybe Joe has thoughts on the matter.

I did use CancelAndForgetObserver in the patch for bug 619899 (which basically does what my addon does, but implemented properly), but there's a comment in imgIRequest.idl saying that it shouldn't be used for new code.

CancelAndForgetObserver should be used from the destructor or similar places (i.e. "omg I'm going away right now"); ideally it wouldn't be necessary at all, but due to the way imagelib delivers notifications, that can't be guaranteed.

It doesn't look like there are any crashes from people with version 3.7.2 of the addon installed (which has a fix). So hopefully, this should start to drop over the next couple of days

(In reply to Chris Coulson from comment #11)
> So hopefully, this should start to drop over the next couple of days
It seems so as it's now #9 top crasher in 19.0 on Linux.