1090672 - crash SIGILL in vp9_idct32x32_1_add_sse2 starting Flash

Status: RESOLVED DUPLICATE of bug 1074860

(Core :: Audio/Video, defect)

Description

[Tony Mechelynck [:tonymec]]

This bug was filed from the Socorro interface and is 
report bp-26ddf5ea-55d7-4ecf-838d-b449d2141029.
=============================================================
Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33a1 ID:20141028003001 c-c:e6d1e266c21a m-c:a255a234946e

Reproducible: Didn't try

Steps to reproduce:
1. Start a Flash video. (The one which caused this was 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 )

Actual result: Crash

Expected result: No crash

Additional info:
- Shortly after this crash, I installed the upgrade from version 11.2.202.406-66.1 to version 11.2.202.411-70.1 of packages "flash-player", "flash-player-gnome" and "flash-player-kde4" from the openSUSE Linux online update site's "non-OSS" repository. These packages are for architecture x86_64 just like the rest of my software. The Plugins tab of my add-ons manager now lists 11.2.202.411 as the version of "Shockwave Flash" but this is after the upgrade.
- I have click-to-play set for most plugins including Flash. There may be sitewise exceptions but not for demotivateur.fr AFAIK.

=============================================================
Here comes the Socorro crash report
=============================================================

Signature 	vp9_idct32x32_1_add_sse2 More Reports Search
UUID 	26ddf5ea-55d7-4ecf-838d-b449d2141029
Date Processed	2014-10-29 00:39:07.031195
Uptime	30653
Last Crash	219422 seconds before submission
Install Age 	30653 since version was first installed.
Install Time 	2014-10-28 16:05:21
Product 	SeaMonkey
Version 	2.33a1
Build ID 	20141028003001
Release Channel 	nightly
OS 	Linux
OS Version 	0.0.0 Linux 3.11.10-21-desktop #1 SMP PREEMPT Mon Jul 21 15:28:46 UTC 2014 (9a9565d) x86_64
Build Architecture 	amd64
Build Architecture Info 	family 15 model 4 stepping 1 | 2
Crash Reason 	SIGILL
Crash Address 	0x7fde401994e1
User Comments 	launching a Flash video. The whole app crashed, not only the plugin.
App Notes 	

OpenGL: VMware, Inc. -- Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits) -- 2.1 Mesa 9.2.3 -- texture_from_pixmap

Processor Notes 	sp-processor09_phx1_mozilla_com.28530:2012; HybridCrashProcessor
EMCheckCompatibility 	

False

Winsock LSP 	

Adapter Vendor ID 	

Adapter Device ID 	

Bugzilla - Report this bug in SeaMonkey Core Plugins Toolkit
Related Bugs

Crashing Thread
Frame 	Module 	Signature 	Source
0 	libxul.so 	vp9_idct32x32_1_add_sse2 	/tools/gcc-4.7.3-0moz1/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include/emmintrin.h:593
1 	libxul.so 	inverse_transform_block 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vp9/decoder/vp9_decodeframe.c:219
2 	libxul.so 	predict_and_reconstruct_intra_block 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vp9/decoder/vp9_decodeframe.c:269
3 	libxul.so 	vp9_foreach_transformed_block_in_plane 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vp9/common/vp9_blockd.c:85
4 	libxul.so 	vp9_foreach_transformed_block 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vp9/common/vp9_blockd.c:96
5 	libxul.so 	decode_block 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vp9/decoder/vp9_decodeframe.c:362
6 	libxul.so 	decode_partition 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vp9/decoder/vp9_decodeframe.c:442
7 	libxul.so 	decode_tiles 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vp9/decoder/vp9_decodeframe.c:898
8 	libxul.so 	vp9_decode_frame 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vp9/decoder/vp9_decodeframe.c:1460
9 	libxul.so 	vp9_receive_compressed_data 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vp9/decoder/vp9_decoder.c:262
10 	libxul.so 	decode_one 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vp9/vp9_dx_iface.c:312
11 	libxul.so 	decoder_decode 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vp9/vp9_dx_iface.c:411
12 	libxul.so 	vpx_codec_decode 	/builds/slave/c-cen-t-lnx64/build/mozilla/media/libvpx/vpx/src/vpx_decoder.c:122
13 	libxul.so 	mozilla::WebMReader::DecodeVideoFrame(bool&, long) 	dom/media/webm/WebMReader.cpp
14 	libxul.so 	mozilla::MediaDecoderReader::RequestVideoData(bool, long) 	dom/media/MediaDecoderReader.cpp
15 	libxul.so 	mozilla::MediaDecoderStateMachine::DecodeMetadata() 	dom/media/MediaDecoderStateMachine.cpp
16 	libxul.so 	mozilla::MediaDecoderStateMachine::CallDecodeMetadata() 	dom/media/MediaDecoderStateMachine.cpp
17 	libxul.so 	nsRunnableMethodImpl<void (mozilla::MediaDecoderStateMachine::*)(), void, true>::Run() 	xpcom/glue/nsThreadUtils.h
18 	libxul.so 	mozilla::MediaTaskQueue::Runner::Run() 	dom/media/MediaTaskQueue.cpp
19 	libxul.so 	nsThreadPool::Run() 	xpcom/threads/nsThreadPool.cpp
20 	libxul.so 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
21 	libxul.so 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp
22 	libxul.so 	mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp
23 	libxul.so 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc
24 	libxul.so 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp
25 	libnspr4.so 	_pt_root 	/builds/slave/c-cen-t-lnx64/build/mozilla/nsprpub/pr/src/pthreads/ptthread.c:212
Ø 26 	libpthread-2.18.so 	libpthread-2.18.so@0x80da 	
Ø 27 	libc-2.18.so 	libc-2.18.so@0xe758c

Comment 1

[Tony Mechelynck [:tonymec]]

P.S. That particular video is syndicated from YouTube and I think I _do_ have a CTP exception for YouTube. (How do I remove it?)

Comment 2

[Benjamin Smedberg]

This crash doesn't appear to have anything to do with Flash: it's in our VP9 decoding code used for HTML <video>. You may be experiencing this on nightly builds since we recently landed VP9+MSE code which youtube uses by default.

We're in the SSE2 codepath of VP9: is your CPU perhaps not SSE2-capable?

Comment 3

[Tony Mechelynck [:tonymec]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> This crash doesn't appear to have anything to do with Flash: it's in our VP9
> decoding code used for HTML <video>. You may be experiencing this on nightly
> builds since we recently landed VP9+MSE code which youtube uses by default.
> 
> We're in the SSE2 codepath of VP9: is your CPU perhaps not SSE2-capable?

It's an Intel Pentium 4 HT, here is a copy of /proc/cpuinfo :

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 4
model name	: Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping	: 1
microcode	: 0x17
cpu MHz		: 2793.146
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
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
bogomips	: 5586.29
clflush size	: 64
cache_alignment	: 128
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 15
model		: 4
model name	: Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping	: 1
microcode	: 0x17
cpu MHz		: 2793.146
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
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
bogomips	: 5586.29
clflush size	: 64
cache_alignment	: 128
address sizes	: 36 bits physical, 48 bits virtual
power management:

Comment 4

[Benjamin Smedberg]

Are you comfortable using a debugger? I'd be interested to see what GDB says the illegal instruction actually is here, and extracting that from the minidump isn't easy. You'll have to disable crash reporting by setting MOZ_CRASHREPORTER_DISABLE=1 in your environment before running.

Comment 5

[Tony Mechelynck [:tonymec]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> Are you comfortable using a debugger? I'd be interested to see what GDB says
> the illegal instruction actually is here, and extracting that from the
> minidump isn't easy. You'll have to disable crash reporting by setting
> MOZ_CRASHREPORTER_DISABLE=1 in your environment before running.

I'm not very comfortable using gdb, but I'll try.

Comment 6

[Tony Mechelynck [:tonymec]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> Are you comfortable using a debugger? I'd be interested to see what GDB says
> the illegal instruction actually is here, and extracting that from the
> minidump isn't easy. You'll have to disable crash reporting by setting
> MOZ_CRASHREPORTER_DISABLE=1 in your environment before running.

Didn't work (out of memory?) The session being debugged got SIGSEGV even before opening its first window. The last stuff displayed were a number of lines containing

(some number)  addons.xpi  DEBUG  getModTime: Recursive scan of (addon ID).

Let's try differently (start SeaMonkey with that "special" environment variable, but don't start the video yet; attach gdb; then start the video).

Comment 7

[Tony Mechelynck [:tonymec]]

After attaching, I se the following, none of which seems relevant:
(gdb finds libraries, ending with:)
Loaded symbols for /usr/lib64/liborc-test-0.4.so.0
0x00007f6f0546bcda in nsCOMPtr_base::begin_assignment() () from /usr/local/seamonkey/libxul.so
(gdb) cont
Continuing.

Program received signal SIG38, Real-time event 38.
0x00007f6f0546bcda in nsCOMPtr_base::begin_assignment() () from /usr/local/seamonkey/libxul.so
(gdb) cont
Continuing.

Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7f6ef53d3700 (LWP 25698)]
0x00007f6f0bf0a014 in send () from /lib64/libpthread.so.0
(gdb) cont
Continuing.

Program received signal SIG38, Real-time event 38.
[Switching to Thread 0x7f6f0c2ed740 (LWP 25690)]
0x00007f6f06df97d0 in JS_PropertyStub(JSContext*, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) ()
   from /usr/local/seamonkey/libxul.so
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00007f6f06cfc13d in js::jit::JitRuntime::patchIonBackedges(JSRuntime*, js::jit::JitRuntime::BackedgeTarget) ()
   from /usr/local/seamonkey/libxul.so
(gdb) 

I felt it wasn't useful to continue after this point.

Comment 8

[Tony Mechelynck [:tonymec]]

P.S. On going back from the gdb console to the SeaMonkey window, where I had not yet started the video, I noticed that mutter-dialog had opened above it. That's a dialog from my window manager, a useless dialog if I ever saw one; it was saying that SeaMonkey had stopped responding, and asking if I wanted to kill or wait. I suspect that this dialog (and possibly the associated watchdog) had interfered with the debugging session.

If I knew how to disable that dialog (make it "always wait" without ever asking anything), it would make me happier.

Comment 9

[Tony Mechelynck [:tonymec]]

I have a different gcc version installed, but this is what I find at /usr/lib64/gcc/x86_64-suse-linux/4.8/include/emmintrin.h lines 588-594:

extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, __artificial__))
_mm_set_epi16 (short __q7, short __q6, short __q5, short __q4,
	       short __q3, short __q2, short __q1, short __q0)
{
  return __extension__ (__m128i)(__v8hi){
    __q0, __q1, __q2, __q3, __q4, __q5, __q6, __q7 };
}

Not necessarily relevant: if you could check the gcc 4.7.3 emmintrin.h as installed on Mozilla build machines it would probably be better.

Comment 10

[cajbir (:cajbir)]

Same underlying bug as bug 1074860. The running theory is VP9 runtime CPU detection is broken. Enabling MSE has resulted in more VP9 content being consumed since YouTube sends VP9 to MSE clients.

Comment 11

[Tony Mechelynck [:tonymec]]

(In reply to cajbir (:cajbir) from comment #10)
> Same underlying bug as bug 1074860. The running theory is VP9 runtime CPU
> detection is broken. Enabling MSE has resulted in more VP9 content being
> consumed since YouTube sends VP9 to MSE clients.

Indeed, I don't see "sse4" in the "Flags" of my CPU (comment #3). Isn't this an outright dupe then?

Comment 12

[John Drinkwater (:beta)]

(In reply to Tony Mechelynck [:tonymec] from comment #11)
> Indeed, I don't see "sse4" in the "Flags" of my CPU (comment #3). Isn't this
> an outright dupe then?

Looks to be!

(For future gdbing: to get the instruction that was causing the issue, use `layout asm` after gdb catches the sigill, will get output like https://bugzilla.mozilla.org/show_bug.cgi?id=1074860#c9 :) )

Comment 13

[Tony Mechelynck [:tonymec]]

(In reply to John Drinkwater (:beta) from comment #12)
> (In reply to Tony Mechelynck [:tonymec] from comment #11)
> > Indeed, I don't see "sse4" in the "Flags" of my CPU (comment #3). Isn't this
> > an outright dupe then?
> 
> Looks to be!

Let's set it then.
> 
> (For future gdbing: to get the instruction that was causing the issue, use
> `layout asm` after gdb catches the sigill, will get output like
> https://bugzilla.mozilla.org/show_bug.cgi?id=1074860#c9 :) )

Ah, thanks.

Comment 14

[Tony Mechelynck [:tonymec]]

This bug has diappeared, see bug 1074860 comment #29.

Comment 15

[Tony Mechelynck [:tonymec]]

P.S. s/diappeared/disappeared/