It first appeared in 14.0a1/20120317. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e5f6caa40409&tochange=ecaad3ae9964 It's likely caused by bug 732820. Signature mozilla::image::DiscardTracker::EnableTimer More Reports Search UUID eb00b0b3-78d7-4816-bfc4-db7cf2120317 Date Processed 2012-03-17 16:41:05 Uptime 3 Last Crash 1.3 hours before submission Install Age 2.8 hours since version was first installed. Install Time 2012-03-17 13:53:43 Product Firefox Version 14.0a1 Build ID 20120317031150 Release Channel nightly OS Linux OS Version 0.0.0 Linux 2.6.38-13-generic #56-Ubuntu SMP Tue Feb 14 12:39:59 UTC 2012 x86_64 Build Architecture amd64 Build Architecture Info family 6 model 23 stepping 10 Crash Reason SIGSEGV Crash Address 0x0 App Notes OpenGL: Tungsten Graphics, Inc -- Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20100330 DEVELOPMENT -- 2.1 Mesa 7.10.2 -- texture_from_pixmap Processor Notes WARNING: JSON file missing Add-ons EMCheckCompatibility False Frame Module Signature Source 0 libxul.so mozilla::image::DiscardTracker::EnableTimer image/src/DiscardTracker.cpp:208 1 libxul.so mozilla::image::DiscardTracker::Reset image/src/DiscardTracker.cpp:78 2 libxul.so mozilla::image::RasterImage::UnlockImage image/src/RasterImage.cpp:2691 3 libxul.so imgRequestProxy::~imgRequestProxy image/src/imgRequestProxy.cpp:100 4 libxul.so imgRequestProxy::~imgRequestProxy image/src/imgRequestProxy.cpp:125 5 libxul.so imgRequestProxy::Release image/src/imgRequestProxy.cpp:61 6 libxul.so nsCSSValue::Image::~Image nsCOMPtr.h:480 7 libxul.so nsCSSValue::Image::Release layout/style/nsCSSValue.h:524 8 libxul.so nsCSSValue::DoReset layout/style/nsCSSValue.cpp:319 9 libxul.so nsCSSCompressedDataBlock::~nsCSSCompressedDataBlock layout/style/nsCSSValue.h:409 10 libxul.so mozilla::css::Declaration::~Declaration nsAutoPtr.h:105 11 libxul.so mozilla::css::StyleRule::~StyleRule layout/style/StyleRule.cpp:1344 12 libxul.so mozilla::css::Rule::Release layout/style/nsCSSRules.cpp:89 13 libxul.so ReleaseObjects obj-firefox/xpcom/build/nsCOMArray.cpp:167 14 libxul.so nsVoidArray::EnumerateForwards obj-firefox/xpcom/build/nsVoidArray.cpp:722 15 libxul.so nsCOMArray_base::~nsCOMArray_base obj-firefox/xpcom/build/nsCOMArray.cpp:177 16 libxul.so nsCSSStyleSheetInner::~nsCSSStyleSheetInner nsCOMArray.h:172 17 libxul.so nsCSSStyleSheetInner::RemoveSheet layout/style/nsCSSStyleSheet.cpp:947 18 libxul.so nsCSSStyleSheet::~nsCSSStyleSheet layout/style/nsCSSStyleSheet.cpp:1103 19 libxul.so nsCSSStyleSheet::~nsCSSStyleSheet layout/style/nsCSSStyleSheet.cpp:1111 20 libxul.so nsCSSStyleSheet::Release layout/style/nsCSSStyleSheet.cpp:1131 21 libxul.so nsTArray<nsRefPtr<nsCSSStyleSheet>, nsTArrayDefaultAllocator>::DestructRange nsTArray.h:1231 22 libxul.so nsTArray<nsRefPtr<nsCSSStyleSheet>, nsTArrayDefaultAllocator>::RemoveElementsAt nsTArray.h:961 23 libxul.so nsTArray<nsRefPtr<nsCSSStyleSheet>, nsTArrayDefaultAllocator>::~nsTArray nsTArray.h:480 24 libxul.so nsXBLPrototypeBinding::~nsXBLPrototypeBinding content/xbl/src/nsXBLPrototypeBinding.cpp:437 25 libxul.so DeletePrototypeBinding content/xbl/src/nsXBLDocumentInfo.cpp:581 26 libxul.so hashEnumerateRemove xpcom/ds/nsHashtable.cpp:327 27 libxul.so PL_DHashTableEnumerate obj-firefox/xpcom/build/pldhash.cpp:750 28 libxul.so nsHashtable::Reset xpcom/ds/nsHashtable.cpp:350 29 libxul.so nsObjectHashtable::~nsObjectHashtable xpcom/ds/nsHashtable.cpp:733 30 libxul.so nsObjectHashtable::~nsObjectHashtable xpcom/ds/nsHashtable.cpp:734 31 libxul.so nsXBLDocumentInfo::~nsXBLDocumentInfo content/xbl/src/nsXBLDocumentInfo.cpp:557 32 libxul.so nsXBLDocumentInfo::~nsXBLDocumentInfo content/xbl/src/nsXBLDocumentInfo.cpp:559 33 libxul.so nsXBLDocumentInfo::Release content/xbl/src/nsXBLDocumentInfo.cpp:524 34 libxul.so XBLFinalize content/xbl/src/nsXBLBinding.cpp:111 ... More reports at: https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Aimage%3A%3ADiscardTracker%3A%3AEnableTimer
> It's likely caused by bug 732820. Almost certainly.
Ouch! Does this bug imply that each and every Nightly user has to download and reinstall Nightly again manually. Or are just some of the Linux users affected?
(In reply to Thomas Ahlblom from comment #2) > Ouch! Does this bug imply that each and every Nightly user has to download > and reinstall Nightly again manually. Or are just some of the Linux users > affected? Things don't actually appear to be that bad. I had many crashes on startup earlier, but after I rebooted my laptop Nightly started without problem. It might stay up long enough to download a new version (as soon as this is fixed). The crashes connected with this bug report are all Linux.
I see ABORT: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0' with stack NS_DebugBreak_P | nsCOMPtr<nsITimer>::operator->() | mozilla::image::DiscardTracker::EnableTimer() mozilla::image::DiscardTracker::Reset(mozilla::image::DiscardTracker::Node*) mozilla::image::RasterImage::UnlockImage() imgRequestProxy::UnlockImage() nsDocument::RemoveImage(imgIRequest*) across all platforms. These do not appear to be start up crashes. So far I've seen 77 urls abort. As soon as my builds finish I'll try to get a reproducible test case.
> with stack Is this perchance happening off the main thread?
Unless someone is calling in here from another thread -- which would definitely be problematic -- or unless our do_CreateInstance is failing (is this not infallible?), I don't see how can happen. I'll post a fix which wallpapers over the problem, but I'd like to understand what's going on...
Created attachment 606981 [details] [diff] [review] Patch v1
Created attachment 606982 [details] log + gdb stack on Mac Thread 0. I can post a crash report if that helps in addition to the crash-stats ones. I've attached a log and gdb session from Mac. I see a funny JS related stack immediately following the abort but the bt in gdb shows this image related stack. This appears to be related to the use of the Spider extension I use in testing. I've tested these manually just loading the urls and can not reproduce but if I run them under Spider it reproduces the abort. This also requires the option of quit upon load. Not sure if that is a bug in Spider or indicative of this bug though I haven't seen it before now. Anyway, to reproduce install http://bclary.com/projects/spider/spider/spider.xpi and then from the command line (after doing your normal environment disable assertion dialog etc foo) do firefox -spider -start -quit -url 'http://forum.ru-board.com/topic.cgi?forum=35&bm=1&topic=47548&start=1160#lt'
Oh, I see. This crash is happening during XPCOM shutdown. At that point, the timer has been nulled out.
Created attachment 606983 [details] [diff] [review] Patch v2
FYI We've been seeing this cause orange on the Thunderbird tinderboxes. Early results from pushing the patch to our try server indicate that the patch fixes it for us.
Comment on attachment 606983 [details] [diff] [review] Patch v2 Review of attachment 606983 [details] [diff] [review]: ----------------------------------------------------------------- This isn't just a wallpaper, though, right?
(In reply to Joe Drew (:JOEDREW!) from comment #14) > This isn't just a wallpaper, though, right? Correct, that was patch v1. Once I saw shutdown xpcom in the stack, that suggested what was going on.
(In reply to Justin Lebar [:jlebar] from comment #15) > (In reply to Joe Drew (:JOEDREW!) from comment #14) > > This isn't just a wallpaper, though, right? > > Correct, that was patch v1. Once I saw shutdown xpcom in the stack, that > suggested what was going on. Oh, but you mean, the commit message! Yes, that's wrong. Thanks for noticing. :)
i have hit this crash a couple of times while doing an update of a nightly build. has occured on xul builds also. https://crash-stats.mozilla.com/report/index/bp-89859a18-4113-43e3-9da8-2f6ec2120320
Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120320 Firefox/14.0a1 I've found that this bug is 100% reproducible only if I start Firefox with '-P' or '-ProfileManager', but so far it has never happened at all if I omit those flags. That may also explain why there's "just" a few hundreds of crash reports.
(In reply to Thomas Ahlblom from comment #19) > Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120320 Firefox/14.0a1 > > I've found that this bug is 100% reproducible only if I start Firefox with > '-P' or '-ProfileManager', but so far it has never happened at all if I omit > those flags. > > That may also explain why there's "just" a few hundreds of crash reports. Practically same here. '-P default' boots normally, starting with profile manager crashes immediately after selecting profile and pressing 'start'
fwiw, in crash automation I hit this on 269 urls between 2012-03-17 and 2012-03-22 but have not seen it since.