Intermittent dom/animation/test/css-animations/test_animation-cancel.html | application crashed [@ nsJARProtocolHandler::AddRef()]

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
2 years ago
2 years ago

People

(Reporter: intermittent-bug-filer, Unassigned)

Tracking

({intermittent-failure})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-active])

I don't see anything animation-related in the stack. Might have just been unlucky that it crashed on this test. I'll wait and see if it happens again.
This hasn't happened again so there's no reason to think that the animation-test it happened to fail on is related. Judging by the stack it seems more likely to be related to networking so shifting there now.
Component: DOM: Animation → Networking
As there's a whole series of functions in the stack trace that are cache related, I'll narrow the guess a bit to that area.

Michal, any clues?
Component: Networking → Networking: Cache
Flags: needinfo?(michal.novotny)
The top 3 frames in the stack look really weird and make no sense. Interesting are frames 6 and 7. AutoClose::takeOver calls Close() on the old pointer before it releases it, this means that mCacheInputStream contained something when takeOver was called. AFAICS mCacheInputStream is set only in nsHttpChannel::OpenCacheInputStream. Honza, when exactly can be this method call twice?
Flags: needinfo?(michal.novotny) → needinfo?(honzab.moz)
(In reply to Michal Novotny (:michal) from comment #4)
> The top 3 frames in the stack look really weird and make no sense.

It's code sharing, optimization made by the compiler.

You can read it as:

0 CacheFile::AddRef()
1 RefPtr<CacheFile>::RefPtr<CacheFile>

The rest is OK.

> Interesting are frames 6 and 7. AutoClose::takeOver calls Close() on the old
> pointer before it releases it, this means that mCacheInputStream contained
> something when takeOver was called. AFAICS mCacheInputStream is set only in
> nsHttpChannel::OpenCacheInputStream. Honza, when exactly can be this method
> call twice?

It can be, potentially (not sure exactly when).  But anyway, it should not matter.  Apparently CacheFile is dead (freed and the memory has been poisoned - e5 memset.  It's a bit strange, since the input stream holds a strong ref to it as well as the cache entry.  

Could this be a memory corruption coming from a different code?  I'm not sure if jemalloc allows that.  happened once, so it could be some corner case.  It's not likely to be a cache2 bug.
Flags: needinfo?(honzab.moz)
I have put it to necko-active, its memory corruption or uaf.
Whiteboard: [necko-active]
Actually there is only 2 case, and the last on was on 13th July. I will close the bug, we can reopen it if it shows up.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.