476349 - Crash [@ imgLoader::RemoveFromCache] [@ nsTArray_base::Length]

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect, P1)

Description

[[e-mail]]

Stack:
imglib2!imgCacheEntry::SetEvicted+0x11 (imgLoader.h:159)
imglib2!imgLoader::RemoveFromCache+0x1df (imgLoader.cpp:1059)
imglib2!imgCacheExpirationTracker::NotifyExpired+0x111 (imgLoader.cpp:499)
imglib2!nsExpirationTracker<imgCacheEntry,3>::AgeOneGeneration+0xcb
imglib2!nsExpirationTracker<imgCacheEntry,3>::TimerCallback+0x14
xpcom_core!nsTimerImpl::Fire+0x28a
xpcom_core!nsTimerEvent::Run+0xa1
xpcom_core!nsThread::ProcessNextEvent+0x1f3
xpcom_core!NS_ProcessNextEvent_P+0x51
xpcom_core!nsThread::Shutdown+0x141
xpcom_core!NS_InvokeByIndex_P+0x27
xpcom_core!nsProxyObjectCallInfo::Run+0x51
xpcom_core!nsThread::ProcessNextEvent+0x1f3
xpcom_core!NS_ProcessNextEvent_P+0x51
gkwidget!nsBaseAppShell::Run+0x5d
tkitcmps!nsAppStartup::Run+0x69
xul!XRE_main+0x2ead
seamonkey!NS_internal_main+0x10c
seamonkey!wmain+0x101
seamonkey!wmainCRTStartup+0x12c
The imgCacheEntry in question is dead for some reason. At a wild guess, it would be because the queue owned the last reference to it.

Comment 1

[[e-mail]]

A retry worked OK, so it's a random crash, not specific to that site :-(

Comment 2

[Wayne Mery (:wsmwk)]

this is suddenly thunderbird #1 topcrash.  All 3 thunderbird comments mention shutdown. 
also Firefox topcrash.
must be from a checkin on 1/31 or early 2/01.

bp-9a7d2db7-dc96-46ae-a552-f710d2090201

nsExpirationTracker<imgCacheEntry,3>::RemoveObject	nsExpirationTracker.h:155
imgLoader::RemoveFromCache	modules/libpr0n/src/imgLoader.cpp:1055
imgLoader::EvictEntries	modules/libpr0n/src/imgLoader.cpp:1090
imgLoader::ClearChromeImageCache	modules/libpr0n/src/imgLoader.cpp:664
imgLoader::Shutdown	modules/libpr0n/src/imgLoader.cpp:655
nsGenericModule::Shutdown	nsGenericFactory.cpp:340
nsGenericModule::`scalar deleting destructor'	
nsGenericModule::Release	nsGenericFactory.cpp:245
nsRefPtr<nsProxyEventObject>::assign_assuming_AddRef	nsAutoPtr.h:944
nsCOMPtr_base::assign_with_AddRef	nsCOMPtr.cpp:89
info_ClearEntry	xpcom/components/nsStaticComponentLoader.cpp:70
PL_DHashTableFinish	pldhash.c:383
nsComponentManagerImpl::Shutdown	xpcom/components/nsComponentManager.cpp:744
NS_ShutdownXPCOM_P	xpcom/build/nsXPComInit.cpp:848

Comment 3

[Wayne Mery (:wsmwk)]

regression looks to be from Bug 466586 or bug 473161

some crashes also appear on 1/31 builds
http://crash-stats.mozilla.com/?do_query=1&version=Firefox%3A3.1b3pre&version=Firefox%3A3.2a1pre&version=SeaMonkey%3A2.0a3pre&version=Thunderbird%3A3.0b2pre&query_search=stack&query_type=contains&query=imgLoader&date=&range_value=13&range_unit=hours

Comment 5

[Matthias Versen [:Matti]]

upgrading to blocker via bug 476457 (crashes with the JS tests)

Testcase from the duped bug :
http://test.bclary.com/tests/mozilla.org/js/js-test-driver-standards.html?test=js1_5/GC/regress-338653.js;language=type;text/javascript

Comment 6

[Bob Clary [:bc] (inactive)]

fwiw, bisection pointed to bug 466586 as the cause.

Comment 7

[Mark Banner (:standard8)]

I've also seen this on Linux trunk (TB with mozilla-central):
bp-43e5cd2a-ee76-4d2f-a836-1f0c52090131 and I think that's just TB restarting
after an extension check dialog came up.

Comment 8

[Carsten Book [:Tomcat]]

blocking beta 3 ?

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

That it's failing a test and related to crashes does indeed imply that it blocks. Re-assigning to Vlad as Joe's on vacation, he can find another assignee. 

(In reply to comment #6)
> fwiw, bisection pointed to bug 466586 as the cause.

If that's the case, I recommend we back out 466586 as it's not a P1 blocker for b3.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

FWIW, on OSX when I try to run the testcase in comment 5 I get a slow script warning and:

BUGNUMBER: 338653
STATUS: Force GC when JSRuntime.gcMallocBytes hits JSRuntime.gcMaxMallocBytes
This test should never fail explicitly. You must view the memory usage during the test. This test fails if the memory usage repeatedly spikes by several hundred megabytes. 

But no crash.

Comment 11

[Tony Chung [:tchung]]

oops, i was just trying to cc myself, and it blew away the flags.  sorry!  please + the blocking1.91 flag again.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Mid-air collision warnings should be heeded for all things other than cc's or comments. :)

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Yeah, I'm having a hard time reproducing this -- I get what beltzner gets.  Anyone have a better testcase?

Comment 14

[IU]

(In reply to comment #13)
> Yeah, I'm having a hard time reproducing this -- I get what beltzner gets. 
> Anyone have a better testcase?

See if this works for you (perform ALL steps).  You may have to repeat Steps 5 to 10 if you do not initially crash:

1. Install (or extract) the latest Shredder nightly
2. If you don't already have a working profile, create one, along with a dummy mail account (to remove the nag).  Also go go "Tools --> Options... --> Advanced --> General" and uncheck "Always check to see if Shredder is the default mail client on startup", to also remove that nag.
4. Make sure Shredder is NOT in "Work Offline" mode
5. Extract the attached sample.zip to your file system
6. Shutdown Shredder
7. Launch Shredder
8. Double-click the sample.eml file you extracted
9. Close the email by clicking the "X" at top right corner.
10. Close Shredder by clicking the "X" at top right corner.

In my case, I crash at least every second or third try of Steps 6 to 10.  It may or may not work for you.

Comment 15

[IU]

Attachment: Test file for Comment #14

Comment 16

[Bob Clary [:bc] (inactive)]

Attachment: additional tests which crash

try loading the links in this file then shutting down the browser. These crash on linux for me.

Comment 17

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I backed out the original patch on 1.9.1; it's still on the trunk because the tree's in flames over there.

Comment 18

[Marcia Knous [:marcia]]

I realize this is still on the trunk, but in my case on the Mac Air I am testing I crashed x2 while starting up in a new profile in this stack - http://crash-stats.mozilla.com/report/index/4e1bf66d-5637-4614-9e7e-364592090203.

Comment 19

[Mark Banner (:standard8)]

Not sure if it helps or not, we've been seeing the following occasional assertions on our Thunderbird Mac bloat box (which basically starts up Thunderbird, opens some windows then closes it all):

###!!! ASSERTION: Tried to remove an object that's not tracked: 'state->IsTracked()', file ../../../dist/include/xpcom/nsExpirationTracker.h, line 149
###!!! ASSERTION: Object is lying about its index: 'generation.Length() > index && generation[index] == aObj', file ../../../dist/include/xpcom/nsExpirationTracker.h, line 153

The first assertion has been seen regularly, the second one popped up on today's (Trunk) failure:

http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird/1233739453.1233741995.10391.gz

Comment 20

[Bob Clary [:bc] (inactive)]

(In reply to comment #17)
> I backed out the original patch on 1.9.1; it's still on the trunk because the
> tree's in flames over there.

Vlad, can we get this backed out of the trunk today? This is causing me problems trying to test the JS Engine on the trunk with so many of the tests crashing.

Comment 21

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Backed out on trunk.  Gonna call this fixed with the backout.  I still was never able to reproduce this, which is going to be a problem as far as getting it fixed goes...

Comment 23

[Wayne Mery (:wsmwk)]

verified - this is gone from recent builds according to crash-stats