Closed
Bug 736761
Opened 13 years ago
Closed 13 years ago
crash in mozilla::image::DiscardTracker::EnableTimer
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
FIXED
mozilla14
People
(Reporter: scoobidiver, Assigned: justin.lebar+bug)
References
Details
(4 keywords, Whiteboard: [startupcrash][native-crash][mobile-crash])
Crash Data
Attachments
(2 files, 1 obsolete file)
14.54 KB,
text/plain
|
Details | |
2.09 KB,
patch
|
joe
:
review+
|
Details | Diff | Splinter Review |
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
Assignee | ||
Comment 1•13 years ago
|
||
> It's likely caused by bug 732820.
Almost certainly.
Assignee: nobody → justin.lebar+bug
Comment 2•13 years ago
|
||
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?
Comment 3•13 years ago
|
||
(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.
Comment 4•13 years ago
|
||
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.
Assignee | ||
Comment 6•13 years ago
|
||
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...
Comment 8•13 years ago
|
||
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'
Reporter | ||
Updated•13 years ago
|
Keywords: reproducible
Assignee | ||
Comment 9•13 years ago
|
||
Oh, I see. This crash is happening during XPCOM shutdown. At that point, the timer has been nulled out.
Assignee | ||
Updated•13 years ago
|
Attachment #606981 -
Attachment is obsolete: true
Attachment #606981 -
Flags: review?(joe)
Reporter | ||
Updated•13 years ago
|
Whiteboard: [startupcrash] → [startupcrash][native-crash]
Comment 11•13 years ago
|
||
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 13•13 years ago
|
||
https://tbpl.mozilla.org/php/getParsedLog.php?id=10194242&tree=Mozilla-Inbound
Comment 14•13 years ago
|
||
Comment on attachment 606983 [details] [diff] [review] Patch v2 Review of attachment 606983 [details] [diff] [review]: ----------------------------------------------------------------- This isn't just a wallpaper, though, right?
Attachment #606983 -
Flags: review?(joe) → review+
Assignee | ||
Comment 15•13 years ago
|
||
(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.
Assignee | ||
Comment 16•13 years ago
|
||
(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. :)
Assignee | ||
Updated•13 years ago
|
Target Milestone: --- → mozilla14
Comment 18•13 years ago
|
||
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
Comment 19•13 years ago
|
||
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.
Reporter | ||
Updated•13 years ago
|
Whiteboard: [startupcrash][native-crash] → [startupcrash][native-crash][mobile-crash]
Comment 20•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/4ce96dfc2c16
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 21•13 years ago
|
||
(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'
Comment 22•13 years ago
|
||
fwiw, in crash automation I hit this on 269 urls between 2012-03-17 and 2012-03-22 but have not seen it since.
You need to log in
before you can comment on or make changes to this bug.
Description
•