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

Status: RESOLVED DUPLICATE of bug 1102612

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

Description

[Bobby Holley (:bholley)]

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?

Comment 1

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

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().

Comment 2

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Matt - can I get you to look into this one?

Comment 3

[Matt Woodrow (:mattwoodrow)]

(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?

Comment 4

[Marcia Knous [:marcia]]

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.

Comment 5

[Matt Woodrow (:mattwoodrow)]

Neither of those appear to be this bug (though they are the same as each other, and probably want a bug filed).

Comment 6

[Marcia Knous [:marcia]]

https://crash-stats.mozilla.com/report/index/01ca98ab-0ded-4eed-b981-e6d102150107 seems to be one Windows crash.

Comment 7

[(not reading bugmail) Nick Desaulniers [:\n]]

Haven't seen this since, will follow up if I do.

Comment 8

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Taking off beta blocking list. We will debug a Windows crash dump if we see one.

Comment 9

[Matt Woodrow (:mattwoodrow)]

Dropping priority to P2, given the lack of crash reports.

Comment 10

[Sheila Mooney]

Matt, is this a dup of another bug? Anthony thinks it is.