Closed Bug 1117881 Opened 6 years ago Closed 5 years ago
Crash in mozilla::Resource
Queue::Copy Data(unsigned long long, unsigned int, char*)
https://crash-stats.mozilla.com/report/index/3a295154-0901-40e8-be67-e203b2150104 This is Nick's crash, which he posted on yammer. It like a demuxer race on first glance (since calling out to read releases the demuxer lock), but the buffer passed on is freshly newed, and I don't see how it could be getting switched out from under us. Nick, can you reproduce this reliably?
This can happen if InputExhausted() gets called from the decoder queue after the MediaSource gets torn down. That will call PopSample() which calls SourceBufferResource::Read().
Matt - can I get you to look into this one?
6 years ago
Assignee: nobody → matt.woodrow
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #1) > This can happen if InputExhausted() gets called from the decoder queue after > the MediaSource gets torn down. That will call PopSample() which calls > SourceBufferResource::Read(). Can you explain this more please :) From what I can see, the source data is strongly owned by ResourceItem objects in the ResourceQueue, and the destination pointer was allocated just up the stack in SampleIterator::GetNext. I can't see how either of those could be invalid, so we must instead be adjusting one of them by an invalid offset, or using an invalid length. My guess would be that we're overflowing somewhere, or getting signed/unsigned mixed up. It's hard to tell exactly which from the crash report, though a debugger or minidump would make this fairly easy to track down. I also only see one instance of this crash on crash-stats, are we sure this is critical?
I found two other crashes in nightly that seem similar: https://crash-stats.mozilla.com/report/index/11d36eca-fd50-4fae-b933-89b442150102 https://crash-stats.mozilla.com/report/index/193d8954-ff72-4c47-8066-c02012150104 Neither report had a URL associated with it.
Neither of those appear to be this bug (though they are the same as each other, and probably want a bug filed).
https://crash-stats.mozilla.com/report/index/01ca98ab-0ded-4eed-b981-e6d102150107 seems to be one Windows crash.
Haven't seen this since, will follow up if I do.
Taking off beta blocking list. We will debug a Windows crash dump if we see one.
No longer blocks: ytb37
Dropping priority to P2, given the lack of crash reports.
Priority: P1 → P2
Matt, is this a dup of another bug? Anthony thinks it is.
Priority: P2 → P1
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1102612
You need to log in before you can comment on or make changes to this bug.