Open Bug 1379039 Opened 3 years ago Updated 3 years ago

InvalidArrayIndex_CRASH [@ mozilla::MediaCache::NoteSeek]

Categories

(Core :: Audio/Video: Playback, defect, P3)

defect

Tracking

()

People

(Reporter: kinetik, Assigned: kinetik)

References

Details

(Keywords: crash, testcase)

+++ This bug was initially created as a clone of Bug #1378518 +++

(In reply to Ralph Giles (:rillian) | needinfo me from comment #2)
> Matthew, looks like nestegg is triggering an assert in the MediaCache. Do
> you have time to look at this?

On the nestegg side, it looks like the Cues are parsed incorrectly (the result differs from mkvinfo, at least), causing the first CuePoint to have an invalid CueClusterPosition (in fact, this element doesn't appear in the file for the first CuePoint) and also causing the second CuePoint to be skipped during parsing.  The CueClusterPosition is marked as mandatory in the Matroska spec, so this file may be technically invalid, but nestegg could handle this situation in a nicer way.

|+ Cues at 1477217

nestegg parses CuePoint but ends up with garbage for the CueClusterPosition (possibly causing a parser desync):
| + Cue point at 1477222
|  + Cue time: 0.000s at 1477224
|  + Cue track positions at 1477227
|   + Cue track: 1 at 1477229

This CuePoint is then completely missed in nestegg's Cues list:
| + Cue point at 1477235
|  + Cue time: 13.916s at 1477237
|  + Cue track positions at 1477241
|   + Cue track: 1 at 1477243
|   + Cue cluster position: 357884 at 1477246

Finally, this CuePoint (and later ones) are parsed correctly:
| + Cue point at 1477251
|  + Cue time: 16.500s at 1477253
|  + Cue track positions at 1477257
|   + Cue track: 1 at 1477259
|   + Cue cluster position: 404035 at 1477262
> nestegg parses CuePoint but ends up with garbage for the CueClusterPosition
> (possibly causing a parser desync):
> | + Cue point at 1477222
> |  + Cue time: 0.000s at 1477224
> |  + Cue track positions at 1477227
> |   + Cue track: 1 at 1477229

There is a CueClusterPosition element present here:

00168a60: 001c 53bb 6bfd bb8b b381 00b7 86f7 8101  ..S.k...........
            ^^ ^^^^ ^^   
            Cues (size=125 bytes - valid)
                         ^^
                         CuePoint (11 bytes - valid)
                                     ^^ CueTrackPositions (6 bytes - valid)
                                          ^^ CueTrack (1 byte - valid)
00168a70: f186 d9bb 8eb3 8236 5cb7 88f7 8101 f183  .......6\.......
          ^^ CueClusterPosition (6 bytes - invalid, outside remaining parent element range,
                                 looks like correct size is 1 byte, with value then being 217,
                                 with the Segment offset of 48 that is 265, the correct offset
                                 of the first Cluster)

So the file is definitely invalid due to the incorrectly sized CueClusterPosition element, but mkvinfo handles it more gracefully.
Assignee: nobody → kinetik
The fix for the MediaCache crash should land soon, see bug 1378518.

After this, if you need to check your own work, you can run with MOZ_LOG=MediaResourceIndex:5.
Currently it shows a few `ReadAt(1@239399576240742)` lines, which is what you'd probably want to catch from nestegg.

Good luck!
No longer blocks: grizzly
You need to log in before you can comment on or make changes to this bug.