744652 - Debug builds spamming assertion at startup "###!!! ASSERTION: Existing entry in disk StartupCache.: 'zipItem == nsnull', file mozilla/startupcache/StartupCache.cpp, line 380"

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Since a few weeks ago, I've been hitting some assertions fairly frequently in my debug build.

At startup, I get 6 instances of:
{
###!!! ASSERTION: Existing entry in disk StartupCache.: 'zipItem == nsnull', file ../../mozilla/startupcache/StartupCache.cpp, line 380
}

and then a little while later, I get 6 consecutive instances of this assertion/warning pair:
{
###!!! ASSERTION: Existing entry in disk StartupCache.: 'NS_SUCCEEDED(rv) && hasEntry == false', file ../../mozilla/startupcache/StartupCache.cpp, line 434
WARNING: cache entry deleted but not written to disk.: file ../../mozilla/startupcache/StartupCache.cpp, line 439
}

This isn't in a fresh profile, but it's near-fresh, and I believe I've clobbered it at least once to try to fix this issue (and then the assertions cropped up again after a little while of using a new profile).

Comment 1

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Not sure what caused this, but setting it as "depends-on" the bug that added the assertion, so that this bug isn't completely orphaned.

Comment 2

[Daniel Holbert [:dholbert] (PTO until 2/24)]

I've got two local builds that are identical (aside from a few unrelated patches), and I get the assertion-failure in one but not the other (using the same profile).  I'm wondering if I somehow ended up with a frankenbuild whose only symptom is this assertion-failure.

Rebuilding to see if that affects anything.

Comment 3

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Attachment: backtrace of first assertion

Yeah, I don't hit this in a fresh build, so I'm not sure what's going on.

Here's a backtrace of the first assertion in my affected build, just in case it ends up being useful.

Comment 4

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Resolving as WFM for now, given that I can't reproduce in a fresh build... (not sure what happened to the affected build though)