1074860 - Crash on watching VP9 video on systems without SSE4

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[John Drinkwater (:beta)]

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

Comment 1

[:Gijs (he/him)]

Can you provide a link to an example video?

Comment 2

[John Drinkwater (:beta)]

https://www.youtube.com/watch?v=5Nc68IdNKdg is one such example (you likely have to disable Flash, as it will still prefer)

Comment 3

[:Gijs (he/him)]

(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...

Comment 4

[John Drinkwater (:beta)]

(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…

Comment 5

[John Drinkwater (:beta)]

(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

Comment 6

[John Drinkwater (:beta)]

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

Comment 7

[John Drinkwater (:beta)]

Looks to be an issue with https://bugzilla.mozilla.org/attachment.cgi?id=8494960 from bug 1063356

Comment 8

[John Drinkwater (:beta)]

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?

Comment 9

[John Drinkwater (:beta)]

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

Comment 10

[Alexander L. Slovesnik]

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.

Comment 11

[Alexander L. Slovesnik]

I've got instant crash on https://www.youtube.com/watch?v=u488IWyjY-0&list=UUFBcrywVNeUOqtJgGhPEvQg&index=45

Comment 12

[Alexander L. Slovesnik]

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.

Comment 15

[Rogério Gonçalves]

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.

Comment 16

[Ralph Giles (:rillian)]

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.

Comment 17

[Rogério Gonçalves]

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

Comment 18

[Karl Tomlinson (:karlt)]

The issue was identified in bug 1063356 comment 19, thanks John, before 1063356 relanded.  i.e. https://hg.mozilla.org/mozilla-central/rev/3363b89ef1b7

Comment 19

[Karl Tomlinson (:karlt)]

Attachment: 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.

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=29caebd43ccd

Comment 20

[John Drinkwater (:beta)]

(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[5]: *** [libxul.so] Error 1
 0:34.52 make[4]: *** [toolkit/library/target] Error 2
 0:34.52 make[3]: *** [compile] Error 2
 0:34.52 make[2]: *** [default] Error 2
 0:34.52 make[1]: *** [realbuild] Error 2
 0:34.52 make: *** [build] Error 2
 0:34.55 427 compiler warnings present.

Comment 21

[John Drinkwater (:beta)]

(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.

Comment 22

[Karl Tomlinson (:karlt)]

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.

Comment 24

[John Drinkwater (:beta)]

(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.

Comment 25

[juan becerra [:juanb]]

Adding three related signatures from the top crashers list on nightly which seem to be the same problem.

Comment 26

[Karl Tomlinson (:karlt)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2013f538837c

I don't think we have the infrastructure to test this.

Comment 27

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/2013f538837c

Comment 29

[Tony Mechelynck [:tonymec]]

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)".

Comment 30

[Landry Breuil (:gaston)]

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.....

Comment 31

[Camelia Badau [:cbadau], Desktop Test Engineering]

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.