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 5•13 years ago
|
||
> with stack
Is this perchance happening off the main thread?
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...
Assignee | ||
Comment 7•13 years ago
|
||
Attachment #606981 -
Flags: review?(joe)
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)
Assignee | ||
Comment 10•13 years ago
|
||
Attachment #606983 -
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
|
||
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 | ||
Comment 17•13 years ago
|
||
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
|
||
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
•