User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20140929004005 Steps to reproduce: Visit a YouTube video, one that has been converted to the newer codec VP9 (VP8 videos don’t trigger this) Actual results: This started happening in Nightly a few days ago, bp-144a8ef3-3a87-4190-93a6-041cc2140930
https://www.youtube.com/watch?v=5Nc68IdNKdg is one such example (you likely have to disable Flash, as it will still prefer)
(In reply to John Drinkwater (:beta) from comment #2) > https://www.youtube.com/watch?v=5Nc68IdNKdg is one such example (you likely > have to disable Flash, as it will still prefer) Hrm, interesting. I can't reproduce in my VM - can you reproduce in safe mode? Wonder if this is GPU/hardware-related. I also noticed that on today's nightly, the "stats for nerds" still show webm/vp8.0, vorbis, instead of vp9...
(In reply to :Gijs Kruitbosch from comment #3) > (In reply to John Drinkwater (:beta) from comment #2) > > https://www.youtube.com/watch?v=5Nc68IdNKdg is one such example (you likely > > have to disable Flash, as it will still prefer) > > Hrm, interesting. I can't reproduce in my VM - can you reproduce in safe > mode? Yup, bp-21f1b712-a0c4-4182-b206-b544a2140930 > Wonder if this is GPU/hardware-related. I also noticed that on today's > nightly, the "stats for nerds" still show webm/vp8.0, vorbis, instead of > vp9... Seeing as it is sigill, might just be a compile issue? See that sometimes with pre-release Steam games that compile for native on Intel…
(In reply to :Gijs Kruitbosch from comment #3) > > I also noticed that on today's > nightly, the "stats for nerds" still show webm/vp8.0, vorbis, > instead of vp9... Try this https://www.youtube.com/watch?v=zqblBq-fUJc it does not have a VP8 copy for me, instead showing the ‘Your browser does not currently recognise any of the video formats’ in Aurora, and crashes Nightly. It triggered bp-1c938abd-ba4b-4886-b8a2-49da72141001
Poking more into this, `pinsrq` is being called which is unavailable on my cpu, AMD Phenom II X4 840. │0x7fe78c3f6dee <decode_modes_b+848> mov %r14,-0xd8(%rbp) >│0x7fe78c3f6df5 <decode_modes_b+855> pinsrq $0x1,0x18(%rbp),%xmm2 │0x7fe78c3f6dfd <decode_modes_b+863> mov %ebx,%edx
Looks to be an issue with https://bugzilla.mozilla.org/attachment.cgi?id=8494960 from bug 1063356
As of 2014-10-05 build, this appears resolved. Looks like https://hg.mozilla.org/mozilla-central/rev/84204f793602 removed the SSE4 flag from moz.build Can someone touching that code confirm the change is intended and wont re-occur, and ∴ close this?
This reoccurred in a different function https://crash-stats.mozilla.com/report/index/6f36cc12-7a76-441d-8fa1-2975c2141022 │0x7ff5082e6082 <vp9_idct32x32_1_add_sse2+69> movd %edi,%xmm2 >│0x7ff5082e6086 <vp9_idct32x32_1_add_sse2+73> pshufb 0x9d1071(%rip),%xmm2 # 0x7ff508cb7100 │0x7ff5082e6092 <vp9_idct32x32_1_add_sse2+85> movaps %xmm1,%xmm4 │0x7ff5082e6095 <vp9_idct32x32_1_add_sse2+88> movaps %xmm1,%xmm5 │0x7ff5082e6098 <vp9_idct32x32_1_add_sse2+91> pinsrq $0x0,(%rsi),%xmm3
Summary: Crash on watching VP9 video, inside decode_modes_b → Crash on watching VP9 video on systems without SSE4
I've got few crashes on YouTube video in current nightly with MSE for WebM enabled: https://crash-stats.mozilla.com/report/index/81958edf-cf40-4286-a46e-c9e5e2141025 https://crash-stats.mozilla.com/report/index/9c270bc5-5525-4da7-aca3-d4fcb2141025 https://crash-stats.mozilla.com/report/index/f488035a-4b78-453c-b1f5-49a9c2141025 I assume it's related to this bug? My CPU is AMD Athlon II X4 620.
I've got instant crash on https://www.youtube.com/watch?v=u488IWyjY-0&list=UUFBcrywVNeUOqtJgGhPEvQg&index=45
I've found regression windows on my another computer: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-10-20-03-02-00-mozilla-central/firefox-36.0a1.en-US.linux-i686.tar.bz2 - GOOD http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-10-21-03-02-08-mozilla-central/firefox-36.0a1.en-US.linux-i686.tar.bz2 - CRASHES Regression window - http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=33c0181c4a25&tochange=29fbfc1b31aa Probably caused by Bug 1063356 My CPU on this computer is Intel(R) Pentium(R) 4 CPU 2.93GHz.
Crash Signature: [@ decode_modes_b ] → [@ vp9_idct8x8_12_add_sse2]
Status: UNCONFIRMED → NEW
Ever confirmed: true
I did a downgrade to http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-10-20-03-02-00-mozilla-central/firefox-36.0a1.en-US.linux-x86_64.tar.bz2 suggested on [Comment 12] and it gone back works normally.
I'm not sure what I'm needinfo'd for here. It sounds like the new runtime cpu detection code in libvpx isn't working properly, and is calling sse4 code on machines without support. You can assign this to me if you want, but I may not get to it immediately.
This version is the last that works on my notebook. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-10-24-03-02-00-mozilla-central/firefox-36.0a1.en-US.linux-x86_64.tar.bz2
The issue was identified in bug 1063356 comment 19, thanks John, before 1063356 relanded. i.e. https://hg.mozilla.org/mozilla-central/rev/3363b89ef1b7
Assignee: nobody → karlt
Only the sse4 file needs sse4.1 and runtime detection protects that. The rest of the C code should run on non-sse4.1 systems. https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=29caebd43ccd
Attachment #8514024 - Flags: review?(ted)
(In reply to Karl Tomlinson (:karlt) from comment #19) > Created attachment 8514024 [details] [diff] [review] > don't require sse4.1 to run vpx common code > > Only the sse4 file needs sse4.1 and runtime detection protects that. > The rest of the C code should run on non-sse4.1 systems. This fails to build if a clobber is triggered; yet if I do a full build (which gives me a crashy firefox) and then apply, it will build cleanly. … snip … 0:34.51 /usr/bin/ld.gold.real: error: read-only segment has dynamic relocations 0:34.51 /home/john/code/firefox/media/libvpx/vp8_rtcd_x86_64-linux-gcc.h:553: error: undefined reference to 'vp8_sixtap_predict16x16_ssse3' 0:34.51 /home/john/code/firefox/media/libvpx/vp8_rtcd_x86_64-linux-gcc.h:555: error: undefined reference to 'vp8_sixtap_predict4x4_ssse3' 0:34.51 /home/john/code/firefox/media/libvpx/vp8_rtcd_x86_64-linux-gcc.h:557: error: undefined reference to 'vp8_sixtap_predict8x4_ssse3' 0:34.51 /home/john/code/firefox/media/libvpx/vp8_rtcd_x86_64-linux-gcc.h:559: error: undefined reference to 'vp8_sixtap_predict8x8_ssse3' 0:34.51 /home/john/code/firefox/media/libvpx/./vp9_rtcd_x86_64-linux-gcc.h:893: error: undefined reference to 'vp9_convolve8_ssse3' 0:34.51 /home/john/code/firefox/media/libvpx/./vp9_rtcd_x86_64-linux-gcc.h:895: error: undefined reference to 'vp9_convolve8_avg_ssse3' 0:34.51 /home/john/code/firefox/media/libvpx/./vp9_rtcd_x86_64-linux-gcc.h:897: error: undefined reference to 'vp9_convolve8_avg_horiz_ssse3' 0:34.51 /home/john/code/firefox/media/libvpx/./vp9_rtcd_x86_64-linux-gcc.h:903: error: undefined reference to 'vp9_convolve8_vert_ssse3' 0:34.51 /home/john/code/firefox/media/libvpx/./vp9_rtcd_x86_64-linux-gcc.h:899: error: undefined reference to 'vp9_convolve8_avg_vert_ssse3' 0:34.51 /home/john/code/firefox/media/libvpx/./vp9_rtcd_x86_64-linux-gcc.h:901: error: undefined reference to 'vp9_convolve8_horiz_ssse3' 0:34.52 collect2: error: ld returned 1 exit status 0:34.52 make: *** [libxul.so] Error 1 0:34.52 make: *** [toolkit/library/target] Error 2 0:34.52 make: *** [compile] Error 2 0:34.52 make: *** [default] Error 2 0:34.52 make: *** [realbuild] Error 2 0:34.52 make: *** [build] Error 2 0:34.55 427 compiler warnings present.
(In reply to John Drinkwater (:beta) from comment #20) > This fails to build if a clobber is triggered; yet if I do a full build > (which gives me a crashy firefox) and then apply, it will build cleanly. Sorry, should have also said the patch does indeed fix the issue though, watched the above linked Blow talk in 1080p.
Thanks for testing John. I haven't been able to reproduce the build failure, and I assume the successful try builds also clobber. I wonder whether there might be a separate issue there. It seems odd that those ssse3 symbols are missing when those are defined in the same translation units as sse2 symbols that are not reported missing. (The methods are kind of wrappers, not needing ssse3 in that unit.) Just guessing but I wonder about possibly a system vpx_config.h being used in some place, or a parallel build issue. I heard other reports of having to build multiple times after problems in /media.
5 years ago
No longer blocks: 1090672
Duplicate of this bug: 1090672
(In reply to Karl Tomlinson (:karlt) from comment #22) > Thanks for testing John. I haven't been able to reproduce the build > failure, and I assume the successful try builds also clobber. A late reply, but a fresh build today with patch had no issue building. Chalk that one up to cosmic rays.
Attachment #8514024 - Flags: review?(ted) → review+
Adding three related signatures from the top crashers list on nightly which seem to be the same problem.
https://hg.mozilla.org/integration/mozilla-inbound/rev/2013f538837c I don't think we have the infrastructure to test this.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 SeaMonkey/2.34a1 ID:20141212003001 c-c:46e2006812f2 m-c:5288b15d22de Duplicate bug 1090672 (crash at http://www.demotivateur.fr/article-buzz/ce-spot-montre-ce-qui-se-passe-dans-la-t-te-d-une-petite-fille-quand-vous-lui-dites-qu-elle-est-jolie--1062 when viewing a Youtube video which I originally mistook for Flash) doesn't happen anymore on this Linux64 system. /proc/cpuinfo for this Pentium 4 HT (2.8 GHz) includes the line flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl cid cx16 xtpr from which "sse4" is absent. N.B. I had to set "Fan: silent (minimum noise but possibly reduced CPU performance)" in the BIOS setup because otherwise the computer wouldn't stay up more than a couple of minutes anymore. System throughput is indeed noticeably less than it used to be when I could afford to boot with "Fan: auto (optimum balance of noise reduction vs. CPU speed)".
I think 2013f538837c causes build regressions on systems where the toolchain doesnt support ssse3/sse4.1, see bug 1028827. There was a reason to have those HAVE_TOOLCHAIN_SUPPORT_MSS* config values.....
In the last 2 weeks, in Socorro were: - 2 crashes on 32.0.3(buildID: 20140923175406) and on 35.0.1 (buildID: 20150122214805) - none for Firefox 36. Closing the issue.
You need to log in before you can comment on or make changes to this bug.