Crash on watching VP9 video on systems without SSE4

VERIFIED FIXED in Firefox 36

Status

()

defect
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: beta, Assigned: karlt)

Tracking

(Depends on 2 bugs, 5 keywords)

35 Branch
mozilla36
x86_64
Linux
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox36 verified)

Details

(crash signature)

Attachments

(1 attachment)

Reporter

Description

5 years ago
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

5 years ago
Can you provide a link to an example video?
Flags: needinfo?(john)
Keywords: crash, crashreportid

Updated

5 years ago
Component: Untriaged → Video/Audio
Product: Firefox → Core
Reporter

Comment 2

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

Comment 3

5 years ago
(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...
Reporter

Comment 4

5 years ago
(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…

Updated

5 years ago
Crash Signature: [@ decode_modes_b ]
Reporter

Comment 5

5 years ago
(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
Reporter

Comment 6

5 years ago
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
Reporter

Comment 8

5 years ago
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?
Reporter

Comment 9

5 years ago
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
Reporter

Updated

5 years ago
Crash Signature: [@ decode_modes_b ] → [@ vp9_idct8x8_12_add_sse2]

Updated

5 years ago
Flags: needinfo?(giles)

Updated

5 years ago
Duplicate of this bug: 1089525
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

5 years ago
Duplicate of this bug: 1090538
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.
Flags: needinfo?(giles)
Assignee

Comment 18

5 years ago
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
Assignee

Updated

5 years ago
Blocks: 1090672
Assignee

Comment 19

5 years ago
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)
Reporter

Comment 20

5 years ago
(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.
Reporter

Comment 21

5 years ago
(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.
Assignee

Comment 22

5 years ago
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.
No longer blocks: 1090672
Duplicate of this bug: 1090672
Reporter

Comment 24

5 years ago
(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.
Crash Signature: [@ vp9_idct8x8_12_add_sse2] → [@ vp9_idct8x8_12_add_sse2] [@ vp9_idct8x8_1_add_sse2] [@ vp9_idct32x32_1024_add_sse2] [@ vp9_idct4x4_1_add_sse2]
Assignee

Comment 26

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

I don't think we have the infrastructure to test this.
Flags: in-testsuite-
https://hg.mozilla.org/mozilla-central/rev/2013f538837c
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Assignee

Updated

5 years ago
Duplicate of this bug: 1089724
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)".
Keywords: verifyme
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.....
Depends on: 1028827
Depends on: 1122745
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.