Closed
Bug 1219319
Opened 9 years ago
Closed 9 years ago
crashes in msmpeg2vdec.dll with address 0x700 mainly on Facebook video
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1205083
People
(Reporter: kairo, Unassigned)
References
Details
(Keywords: crash)
Crash Data
[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•9 years ago
|
||
Jean-Yves, do you know of any H.264 changes in FF 42 that might contribute to crashes in WMF on Windows 7?
Flags: needinfo?(jyavenard)
Reporter | ||
Comment 2•9 years ago
|
||
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.
Crash Signature: [@ msmpeg2vdec.dll@0x102f62]
[@ msmpeg2vdec.dll@0x10286a] → [@ msmpeg2vdec.dll@0x102f62]
[@ msmpeg2vdec.dll@0x10286a]
[@ msmpeg2vdec.dll@0x1230b2]
Comment 3•9 years ago
|
||
bug 1205083 got fixed recently but wasn't backported to 42. I duped bug 1218765 to it thinking it is the same problem.
Reporter | ||
Comment 4•9 years ago
|
||
(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.
Reporter | ||
Comment 5•9 years ago
|
||
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.
Reporter | ||
Comment 6•9 years ago
|
||
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•9 years ago
|
||
(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.
Flags: needinfo?(jyavenard)
Comment 8•9 years ago
|
||
Fixed in 43 and 44 by bug 1205083.
Depends on: 1205083
OS: Windows NT → Windows 7
Comment 10•9 years ago
|
||
Bug 1205083 got uplifted to release, so can you track that one instead? This should just be a duplicate.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(lhenry)
Resolution: --- → DUPLICATE
Updated•9 years ago
|
Flags: needinfo?(lhenry)
You need to log in
before you can comment on or make changes to this bug.
Description
•