Last Comment Bug 736761 - crash in mozilla::image::DiscardTracker::EnableTimer
: crash in mozilla::image::DiscardTracker::EnableTimer
Status: RESOLVED FIXED
[startupcrash][native-crash][mobile-c...
: crash, regression, reproducible, topcrash
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: 14 Branch
: All Linux
: -- critical with 2 votes (vote)
: mozilla14
Assigned To: Justin Lebar (not reading bugmail)
:
Mentors:
: 737105 (view as bug list)
Depends on:
Blocks: 532972 732820
  Show dependency treegraph
 
Reported: 2012-03-17 11:25 PDT by Scoobidiver (away)
Modified: 2012-03-27 04:23 PDT (History)
14 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v1 (2.41 KB, patch)
2012-03-18 09:47 PDT, Justin Lebar (not reading bugmail)
no flags Details | Diff | Review
log + gdb stack on Mac (14.54 KB, text/plain)
2012-03-18 09:48 PDT, Bob Clary [:bc:]
no flags Details
Patch v2 (2.09 KB, patch)
2012-03-18 09:56 PDT, Justin Lebar (not reading bugmail)
joe: review+
Details | Diff | Review

Description Scoobidiver (away) 2012-03-17 11:25:02 PDT
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
Comment 1 Justin Lebar (not reading bugmail) 2012-03-17 14:33:43 PDT
> It's likely caused by bug 732820.

Almost certainly.
Comment 2 Thomas Ahlblom 2012-03-17 14:53:01 PDT
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 B.J. Herbison 2012-03-17 21:51:04 PDT
(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 Bob Clary [:bc:] 2012-03-18 08:38:57 PDT
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.
Comment 5 Justin Lebar (not reading bugmail) 2012-03-18 08:52:43 PDT
> with stack

Is this perchance happening off the main thread?
Comment 6 Justin Lebar (not reading bugmail) 2012-03-18 08:59:51 PDT
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 7 Justin Lebar (not reading bugmail) 2012-03-18 09:47:40 PDT
Created attachment 606981 [details] [diff] [review]
Patch v1
Comment 8 Bob Clary [:bc:] 2012-03-18 09:48:32 PDT
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'
Comment 9 Justin Lebar (not reading bugmail) 2012-03-18 09:51:46 PDT
Oh, I see.

This crash is happening during XPCOM shutdown.  At that point, the timer has been nulled out.
Comment 10 Justin Lebar (not reading bugmail) 2012-03-18 09:56:01 PDT
Created attachment 606983 [details] [diff] [review]
Patch v2
Comment 11 Mark Banner (:standard8) 2012-03-19 08:25:22 PDT
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 12 Justin Lebar (not reading bugmail) 2012-03-19 11:40:28 PDT
*** Bug 737105 has been marked as a duplicate of this bug. ***
Comment 14 Joe Drew (not getting mail) 2012-03-20 07:33:17 PDT
Comment on attachment 606983 [details] [diff] [review]
Patch v2

Review of attachment 606983 [details] [diff] [review]:
-----------------------------------------------------------------

This isn't just a wallpaper, though, right?
Comment 15 Justin Lebar (not reading bugmail) 2012-03-20 07:40:11 PDT
(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.
Comment 16 Justin Lebar (not reading bugmail) 2012-03-20 07:44:35 PDT
(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.  :)
Comment 17 Justin Lebar (not reading bugmail) 2012-03-20 08:00:36 PDT
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=4ce96dfc2c16
Comment 18 Bill Gianopoulos [:WG9s] 2012-03-20 15:56:14 PDT
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 Thomas Ahlblom 2012-03-20 16:42:23 PDT
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.
Comment 20 Mounir Lamouri (:mounir) 2012-03-21 03:54:00 PDT
https://hg.mozilla.org/mozilla-central/rev/4ce96dfc2c16
Comment 21 Gaspar Chiligarov 2012-03-22 12:52:30 PDT
(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 Bob Clary [:bc:] 2012-03-27 04:23:57 PDT
fwiw, in crash automation I hit this on 269 urls between 2012-03-17 and 2012-03-22 but have not seen it since.

Note You need to log in before you can comment on or make changes to this bug.