1219319 - crashes in msmpeg2vdec.dll with address 0x700 mainly on Facebook video

Status: RESOLVED DUPLICATE of bug 1205083

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

Description

[Robert Kaiser]

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

This bug was filed from the Socorro interface and is 
report bp-6a20f0e2-fb18-4c37-938c-6c1e62151028.
=============================================================

Those crashes are new in 42 and the stacks are all msmpeg2vdec.dll, the last frame is either msmpeg2vdec.dll@0x102f62 (see the crash linked above) or msmpeg2vdec.dll@0x10286a (e.g. bp-49f56d74-4b75-4644-b00d-7027b2151028). All the crashes are EXCEPTION_ACCESS_VIOLATION_READ at address 0x700.

The @0x102f6 is 100% in msmpeg2vdec.dll 12.0.9200.17037, while the @0x10286a is version 12.0.9200.16426, both are exclusively on Win7.

The signatures have been around at a lower level but started to spike significantly on 2015-10-22 or 2015-10-23 on 42, which is interesting as that doesn't correlate with when we shipped any new beta build (we shipped b8 on the 20th and b9 extremely late on the 23rd so that any new crashes for it would fall into the 24th UTC).

Those two signatures sum up to 3.3% of early 42.0 RC crash data.

Comment 1

[Chris Peterson [:cpeterson]]

Jean-Yves, do you know of any H.264 changes in FF 42 that might contribute to crashes in WMF on Windows 7?

Comment 2

[Robert Kaiser]

While the signatures above are 32bit, there's a msmpeg2vdec.dll@0x1230b2 in 64-bit version 12.0.9200.17037 (also Win7) as well with lower volume (as beta users on 64bit builds are still rather few). It may be interesting that the address in 64bit is still 0x700.

Comment 3

[Guilherme Lima]

bug 1205083 got fixed recently but wasn't backported to 42. I duped bug 1218765 to it thinking it is the same problem.

Comment 4

[Robert Kaiser]

(In reply to Guilherme Lima from comment #3)
> bug 1205083 got fixed recently but wasn't backported to 42. I duped bug
> 1218765 to it thinking it is the same problem.

The bug 1205083 does not have the 0x700 address, it may be something different.

Comment 5

[Robert Kaiser]

Hmm, that said, all the crash reports in this bug stopped on nightly with the build from the 21st, and bug 1205083 landed for the next one. So it looks like the fix from there could actually be what we want for this.

Comment 6

[Robert Kaiser]

For Dev Edition, the data is little, but we don't have crashes in the build from the 27th, which is the first that has the patch from there.

Comment 7

[Jean-Yves Avenard [:jya]]

(In reply to Chris Peterson [:cpeterson] from comment #1)
> Jean-Yves, do you know of any H.264 changes in FF 42 that might contribute
> to crashes in WMF on Windows 7?

Yes.

:cpearce found that this was due to enabling Windows WMF Low Latency Mode.

This was fixed in bug 1205083, but the uplift request for 42 was denied unfortunately.

What's puzzling is that Chrome uses that low latency mode exactly like we do.

Hopefully that decision (on the uplift) will be reversed.

Comment 8

[Chris Peterson [:cpeterson]]

Fixed in 43 and 44 by bug 1205083.

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking belatedly, in case this reopens.

Comment 10

[Ralph Giles (:rillian)]

Bug 1205083 got uplifted to release, so can you track that one instead? This should just be a duplicate.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Not tracking as we probably fixed it.