480352 - Unknown-cause topcrash in imglib [@ nsExpirationTracker<imgCacheEntry, 3>::RemoveObject(imgCacheEntry*) ]

Status: VERIFIED FIXED

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

Description

[Joe Drew (not getting mail)]

There is currently a topcrash in imglib that I haven't found a way to reproduce. It seems to happen only on Windows (at least, the crash reports have come 100% from Windows users), and I haven't found any STR anywhere.

For anybody who's trying to help me debug, setting the environment variables

NSPR_LOG_MODULES="imgRequest:5"
NSPR_LOG_FILE="imgRequest.log"

before running your trunk version of Firefox, and then sending me imgRequest.log when Firefox crashes, are essential to getting this fixed.

Neil Rashbrook has seen this crash in the past.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Happened for me too while using the first tryserver build from Shawn on bug 455555. Do you need more steps?

Comment 2

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

As Joe explained it to me, the fix for bug 466586 has resulted in this topcrash occuring. Since bug 466586 is a P1 blocker, that implies that this is a P1 blocker, although the fact that it's an "unknown cause" makes me worry.

Vlad: what do you suggest we do here? I see a couple of options:

A) Allow bug 466586 to land in B3 and use the additional crash stacks to determine the cause of this crash.

B) Defer bug 466586 to the next beta, and resolve this on trunk.

C) Hold Beta 3 for this bug's fix.

Comment 3

[Mats Palmgren (inactive)]

There's also a topcrash on Linux with the signature:
nsExpirationTracker<imgCacheEntry, 3u>::RemoveObject
Some of the stacks looks like the same bug to me.
bp-646481c8-5149-4cb1-8c33-2e98b2090226
bp-127414a0-6d87-4000-a858-981632090223
bp-714a311a-d3c3-450a-a256-f3da22090220

But others looks like a different crash:
bp-8e0dc0da-739f-4e3a-bc15-1e8152090226
bp-328f3e71-4f26-4daf-89aa-39b9f2090223

Comment 4

[Joe Drew (not getting mail)]

They more than likely all have the same root cause. Thanks, Mats.

Comment 5

[Radek 'sysKin' Czyz]

I had one of those crashes and all I can say is that I visited an image-heavy website but when images were still loading, I closed the window (possibly last browser window. I don't remember).

Comment 6

[Jesse Ruderman]

I wonder if Valgrind would help here.

Comment 7

[Jesse Ruderman]

Sorry, I meant to say "I wonder if bug 479502 fixed this".  The keys are like right next to each other.

Comment 8

[[e-mail]]

My crash totally went away yesterday too, so I also recommend RESO DUPE.

Comment 9

[Joe Drew (not getting mail)]

There are still crashes in crash-stats using 2009-02-26's build, so I don't think so.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Chris, could you give us some of the URLs from the crashes listed here?

http://tinyurl.com/d2wy7b

That would be really helpful to finding a reliable crash test. Thanks.

Comment 11

[Robert Sayre]

Attachment: valgrind log of invalid write during imgcache expiry

maybe this is related?

Comment 12

[Robert Sayre]

(In reply to comment #11)
> Created an attachment (id=364838) [details]
> valgrind log of invalid write during imgcache expiry
> 
> maybe this is related?

Or maybe that's what bug 479502 fixed, sorry.

Comment 13

[Joe Drew (not getting mail)]

Yeah, almost certainly. :(

Comment 14

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

Moved to P2 as per earlier discussion.

Comment 15

[Brian]

Attachment: log of crash using NSPR_LOG_MODULES=all:5

Log remained when using NSPR_LOG_MODULES="imgRequest:5" but when using all:5 generated data. Better than nothing? http://www.animatedengines.com/index.shtml generates crashes for me consistently.

Comment 16

[Henri Sivonen (:hsivonen)]

On Mac, I get a crash with this top of the stack:
0   XUL                           	0x0140556a void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) + 3507818

Same bug? Different one?

Comment 17

[Joe Drew (not getting mail)]

different one. If you can reproduce, please file.

Comment 18

[Henri Sivonen (:hsivonen)]

The crash from comment #16 is now bug 482690.

Comment 19

[(not currently active) Ted Mielczarek]

I crashed with this stack twice in the past two days:
http://crash-stats.mozilla.com/report/index/9c0be68b-4df5-4ca5-8202-6c9a82090319?p=1
http://crash-stats.mozilla.com/report/index/2fd40617-7e6a-4f6f-912f-3b4922090318

The xul.dll frames without symbols weird me out. AFAICT, those really are out in the weeds, but the addresses are consistent, so that makes no sense to me. I'll try NSPR logging, as well as trying to catch it in a debugger.

Comment 20

[Joe Drew (not getting mail)]

If you can continue to reproduce with a build from 20090318 or later, I am *really* interested in that. So far I haven't seen any crashes on crash-stats since I checked in bug 481753.

Comment 21

[(not currently active) Ted Mielczarek]

Those crashes were with 20090317, so here's hoping!

Comment 22

[Joe Drew (not getting mail)]

This was a _very_ common crash that hasn't shown up at all since the 20090317 build - none from 0318 or 0319 have shown up on crash-stats. I'm going to call this fixed, and breathe a sigh of relief.

Comment 23

[Bill Gianopoulos [:WG9s]]

Since a changeset that actually corrected this does not seem to be identified here, isn't the correct resolution for this bug WORKSFORME?

Comment 24

[(not currently active) Ted Mielczarek]

I think Joe is saying that the fix in bug 481753 fixed this.

Comment 25

[Bill Gianopoulos [:WG9s]]

Comments in that bug would indicate you are correct.  WORKSFORME -> FIXED

Comment 27

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Did this land on 1.9.2 yet? Flags indicate no. It's the #31 topcrash in preliminary 3.6b4 data.

Comment 28

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Oh, err, didn't realize how old this bug was. Seems like there's some other bug with the same signature. Will file a separate bug on that.

Nothing to see here people, move along.

Comment 29

[Mats Palmgren (inactive)]

There's still crash reports coming in with this signature.
I filed bug 548102.