736761 - crash in mozilla::image::DiscardTracker::EnableTimer

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Scoobidiver (away)]

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)]

> It's likely caused by bug 732820.

Almost certainly.

Comment 2

[Thomas Ahlblom]

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]

(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] (inactive)]

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)]

> with stack

Is this perchance happening off the main thread?

Comment 6

[Justin Lebar (not reading bugmail)]

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)]

Attachment: Patch v1

Comment 8

[Bob Clary [:bc] (inactive)]

Attachment: 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)]

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)]

Attachment: Patch v2

Comment 11

[Mark Banner (:standard8)]

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

[Ryan VanderMeulen [:RyanVM]]

https://tbpl.mozilla.org/php/getParsedLog.php?id=10194242&tree=Mozilla-Inbound

Comment 14

[Joe Drew (not getting mail)]

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)]

(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)]

(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)]

https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=4ce96dfc2c16

Comment 18

[Bill Gianopoulos [:WG9s]]

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]

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)]

https://hg.mozilla.org/mozilla-central/rev/4ce96dfc2c16

Comment 21

[Gaspar Chiligarov]

(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] (inactive)]

fwiw, in crash automation I hit this on 269 urls between 2012-03-17 and 2012-03-22 but have not seen it since.