Closed Bug 1100260 Opened 5 years ago Closed 5 years ago
crash in ns
TArray _base<ns TArray Infallible Allocator, ns TArray _Copy With Memutils>::Increment Length(unsigned int) | mp4 _demuxer::Moof::Moof(mp4 _demuxer::Moof const&)
I created a video and when I try to load it, firefox is crashing. The buggy movie: http://mitiv.univ-lyon1.fr/images/videos/TVSaturn.mp4 <- Deadly URL The crash report: https://crash-stats.mozilla.com/report/index/c1b3a633-66d7-4d6d-b699-36d292141117 It works on 4 different Ubuntu from 14.04 to 14.10 and also with Firefox nightly version. I don't know if it's relevant but I wanted you to know.
Component: File Handling → Video/Audio
Product: Firefox → Core
On Win 7, FF33 displays an error about corrupted file, but no crash of the browser.
General Unique ID : 85936613925504887967637265929710971969 (0x40A6CA30D8B02E71C7046DE2BEFDAC41) Complete name : TVSaturn.mp4 Format : Matroska Format version : Version 4 / Version 2 File size : 432 KiB Duration : 3s 699ms Overall bit rate : 956 Kbps Encoded date : UTC 2014-10-29 14:46:44 Writing application : mkvmerge v6.7.0 ('Back to the Ground') 64bit built on Jan 9 2014 18:03:17 Writing library : libebml v1.3.0 + libmatroska v1.4.1 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : Main@L4.0 Format settings, CABAC : Yes Format settings, ReFrames : 2 frames Codec ID : V_MPEG4/ISO/AVC Duration : 3s 700ms Bit rate : 937 Kbps Width : 1 918 pixels Height : 1 410 pixels Display aspect ratio : 4:3 Original display aspect ratio : 4:3 Frame rate mode : Variable Frame rate : 30.000 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.012 Stream size : 423 KiB (98%) Writing library : x264 core 142 r2389 956c8d8 Encoding settings : cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=2 / psy=1 / psy_rd=1,00:0,00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=12 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=300 / keyint_min=30 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=crf / mbtree=1 / crf=20,0 / qcomp=0,60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=20000 / vbv_bufsize=25000 / crf_max=0,0 / nal_hrd=none / filler=0 / ip_ratio=1,40 / aq=1:1,00 Language : English Default : Yes Forced : No Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177 Transfer characteristics : BT.709-5, BT.1361 Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177
Crashes (eventually) also on Windows with the MP4Reader. WMFReader reports this file as corrupt. This looks like a variant of Bug 1093567, but this bug also affects GStreamerReader.
I filed bug 1100466 about another issue with this corrupt MP4 in FF35+.
Crash Signature: [@ nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::IncrementLength(unsigned int) | _PR_NativeRunThread | pr_root ]
https://crash-stats.mozilla.com/report/index/e21c87ae-de3f-46e3-a22e-a09852141118 this was also causing my profile to lock up
Status: UNCONFIRMED → NEW
Ever confirmed: true
PS I am on windows
OS: Linux → All
Hardware: x86_64 → All
Using Fx34 (latest beta) on Win8.1 and Win7 machines and I get a "corrupt file" message when trying to play the video in the link in comment #0.
I just hit this in Nightly on shutdown - https://crash-stats.mozilla.com/report/index/7fc8d103-377e-4e6b-861a-812aa2141212
I tried it with the latest Nightly (2014-12-12) and Firefox displayed a tab saying the movie was corrupt.
We got this crash when running the Mozmill test for the home button: * http://hg.mozilla.org/qa/mozmill-tests/file/16b50427082b4d37993c3b9b6a6c3691dc0b5033/firefox/tests/functional/testToolbar/testHomeButton.js Report: https://crash-stats.mozilla.com/report/index/2f324d05-f69f-44c5-a68e-639392141215
Just got this crash after updating flash to latest version and started the browser: https://crash-stats.mozilla.com/report/index/103acfa3-811c-4f7a-87f2-4bd822141217
(In reply to Mihaela Velimiroviciu [QA] (:mihaelav) from comment #12) > Just got this crash after updating flash to latest version and started the > browser: > https://crash-stats.mozilla.com/report/index/103acfa3-811c-4f7a-87f2- > 4bd822141217 Actually, it crashed when disabling e10s.
[Tracking Requested - why for this release]: This is a top-5 crasher in Dev Edition 36 with almost double the volume of the usual #1 OOM|small. Looking at https://crash-stats.mozilla.com/report/list?signature=nsTArray_base%3CnsTArrayInfallibleAllocator%2C%20nsTArray_CopyWithMemutils%3E%3A%3AIncrementLength%28unsigned%20int%29%20%7C%20_PR_NativeRunThread%20%7C%20pr_root it does not happen in 35, but does in 36 and 37.
Kairo: I thought this should have been fixed for Firefox 36 in bug 1093567. I can't reproduce this on Nightly or Beta with the Deadly URL from comment 0 anymore.
(In reply to Chris Pearce (:cpearce) from comment #15) > Kairo: I thought this should have been fixed for Firefox 36 in bug 1093567. The crash signature is still around in the builds from the last two days for sure, and actually seems to be rising in volume.
Hmm, and https://crash-stats.mozilla.com/report/list?signature=nsTArray_base%3CnsTArrayInfallibleAllocator%2C%20nsTArray_CopyWithMemutils%3E%3A%3AIncrementLength%28unsigned%20int%29%20%7C%20mp4_demuxer%3A%3AMoof%3A%3AMoof%28mp4_demuxer%3A%3AMoof%20const%26%29 is rising and looks similar in terms of the signature...
Summary: url with mp4 video makes firefox crash instantly → crash in nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::IncrementLength(unsigned int) | mp4_demuxer::Moof::Moof(mp4_demuxer::Moof const&)
5 years ago
See Also: → 1114383
5 years ago
This isn't a top crash. Bug 1114034 covers that.
I note the bug summary for this current bug already includes crash signature ...:IncrementLength(unsigned int) | _PR_NativeRunThread | pr_root ] (Added after comment 5) That is the same signature as bug 1114034 that makes me wonder is there an intention to class bug 1114034 as duplicate of this one ? (Although I also note bug 1114034 may not always have MP4 playing.)
(In reply to John Hesling [:John99] from comment #20) > I note the bug summary for this current bug already includes crash signature > ...:IncrementLength(unsigned int) | _PR_NativeRunThread | pr_root ] (Added > after comment 5) > > That is the same signature as bug 1114034 that makes me wonder is there an > intention to class bug 1114034 as duplicate of this one ? > > (Although I also note bug 1114034 may not always have MP4 playing.) The top level signature appears different, and the mp4 test case here isn't reliable. Plus I've reproduced bug 1114034 without having played any mp4s, so I split them apart. Since the signature specific to mp4 playback isn't in the top crash list, I don't think this should block. Note, Robert linked to the summary page for the mp4 crash in comment 17 which currently has 362 results for all releases. The signature for bug 1114034 is much much worse.
(In reply to Jim Mathies [:jimm] from comment #19) > This isn't a top crash. Bug 1114034 covers that. OK, not tracking then and updating the keywords
(In reply to Robert Kaiser (:email@example.com) from comment #17) > Hmm, and > https://crash-stats.mozilla.com/report/ > list?signature=nsTArray_base%3CnsTArrayInfallibleAllocator%2C%20nsTArray_Copy > WithMemutils%3E%3A%3AIncrementLength%28unsigned%20int%29%20%7C%20mp4_demuxer% > 3A%3AMoof%3A%3AMoof%28mp4_demuxer%3A%3AMoof%20const%26%29 is rising and > looks similar in terms of the signature... I don't see any of these crashes since the 2014122600 build. Not sure if we think we need to track this for MSE. ni on Anthony to make the call since he added this after seeing comment 17.
Flags: needinfo?(mozillamarcia.knous) → needinfo?(ajones)
It's not crashing on nightly and it is a Matroska file masquerading as an MP4 so it shouldn't play.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.