Closed Bug 1117881 Opened 10 years ago Closed 10 years ago

Crash in mozilla::ResourceQueue::CopyData(unsigned long long, unsigned int, char*)

Categories

(Core :: Audio/Video, defect, P1)

Product:
Core
Component:
Audio/Video
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1102612

People

(Reporter: bholley, Assigned: mattwoodrow)

References

(Blocks 1 open bug,
URL
)

Details

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 new[]ed, and I don't see how it could be getting switched out from under us. Nick, can you reproduce this reliably?
Flags: needinfo?(nick)
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?
Flags: needinfo?(matt.woodrow)
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
Severity: normal → critical
(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?
Neither of those appear to be this bug (though they are the same as each other, and probably want a bug filed).
Blocks: ytb37
Haven't seen this since, will follow up if I do.
Flags: needinfo?(nick)
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.
Flags: needinfo?(matt.woodrow)
Priority: P2 → P1
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(matt.woodrow)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.