Hi, It looks like the binary built packages at FreeBSD assumes SSE optimizations are allowed. This busfaults on my computer. (gdb) info registers rax 0x7fffffff29cc 140737488300492 rbx 0x826790b81 35005205377 rcx 0x0 0 rdx 0x0 0 rsi 0x826790b81 35005205377 rdi 0x826790bbb 35005205435 rbp 0x18 0x18 rsp 0x7fffffff2910 0x7fffffff2910 r8 0x7fffffff29cc 140737488300492 r9 0x1c 28 r10 0x3 3 r11 0x1d 29 r12 0x7fffffff29a0 140737488300448 r13 0x80004005 2147500037 r14 0x46 70 r15 0x8267903a2 35005203362 rip 0x80cce937b 0x80cce937b eflags 0x10246 [ PF ZF IF RF ] cs 0x43 67 ss 0x3b 59 ds <unavailable> es <unavailable> fs <unavailable> gs <unavailable> (gdb) x/i 0x80cce937b => 0x80cce937b: movdqa (%rbx,%rdx,1),%xmm0 (gdb) print *(uint32_t *)0x826790b81 $2 = 1744856832 --HSP
FYI: => 0x80cce937b: movdqa (%rbx,%rdx,1),%xmm0 Is inside libxul.so --HPS
I confirm, firefox crashes here in 93amd64 jail but not in 93i386. amd64 is supposed to guarantee SSE2, so what happens here can be either crt/rtld/libc/libthr bug or miscompilation by lang/gcc5.
Jan: Is it possible to reproduce this with a debug build of Firefox ? GCC guys are asking for some more information. --HPS
Analyzing together with the GCC folks show that the address used with the SSE instruction is not 16-byte aligned like it should. Jan: How can we get debug symbols for the binary package at FreeBSD.org ? --HPS
(In reply to Hans Petter Selasky from comment #3) > Is it possible to reproduce this with a debug build of Firefox ? DEBUG=on enables a lot of runtime checks poorly tested on FreeBSD. Better use just debugging symbols (see below). If the stack trace isn't complete rebuild every package firefox depends. Note, you may need to hack some ports (e.g. multimedia/ffmpeg) that don't respect STRIP variable in order to disable stripping without turning off optimized assembly. # Put into /etc/make.conf or /usr/ports/www/firefox/Makefile.local OPTIONS_UNSET += OPTIMIZED_CFLAGS CFLAGS += -g STRIP = # empty Here's what I get after rebuilding just multimedia/ffmpeg and www/firefox: (gdb) bt #0 0x000000082b3b2330 in ff_vp9_ipred_dc_left_32x32_avx2 () from /usr/local/lib/libavcodec.so.56 #1 0x000000082b214f2a in intra_recon (bytesperpixel=<optimized out>, uv_off=<optimized out>, y_off=<optimized out>, ctx=<optimized out>) at libavcodec/vp9.c:2719 #2 intra_recon_8bpp (ctx=<optimized out>, y_off=<optimized out>, uv_off=32) at libavcodec/vp9.c:2761 #3 0x000000082b24830c in decode_b (ctx=0x826645120, row=0, col=8, lflvl=0x825e36960, yoff=64, uvoff=32, bl=BL_64X64, bp=PARTITION_NONE) at libavcodec/vp9.c:3324 #4 0x000000082b24f19b in decode_sb (ctx=0x826645120, row=0, col=8, lflvl=0x825e36960, yoff=64, uvoff=32, bl=BL_64X64) at libavcodec/vp9.c:3428 #5 0x000000082b25ac44 in vp9_decode_frame (ctx=0x826645120, frame=0x826882420, got_frame=0x82cbdd4d0, pkt=0x82cbdd468) at libavcodec/vp9.c:4181 #6 0x000000082b08f225 in frame_worker_thread (arg=<optimized out>) at libavcodec/pthread_frame.c:161 #7 0x0000000801c58dc4 in ?? () from /lib/libthr.so.3 #8 0x00007ffff9daf000 in ?? () Note, my CPU does support AVX2.
FYI, multimedia/ffmpeg is built by GCC 4.2.1 (patched) on FreeBSD 9.x for which upstream says: WARNING: gcc 4.2 is outdated and may miscompile FFmpeg. Please use a newer compiler.
Can you enter: x/i 0x000000082b3b2330 and info reg In the GDB ? --HPS
That makes sense. I'm using clang 3.6 to build locally and then there was no problem with the firefox binary via /etc/make.conf. Could you try the same?
Created attachment 176747 [details] use clang (workaround) (gdb) x/i 0x0000000828db2330 => 0x828db2330 <ff_vp9_ipred_dc_left_32x32_avx2>: vmovdqa (%rdx),%ymm0 An easier way to reproduce: $ fetch http://base-n.de/webm/out9.webm $ ffmpeg -i out9.webm -y foo.mp4 Does the attached patch fixes your crash?
Hi, I can only test this when the binary build is done. I remember that I only rebuilt firefox, so firefox might need to have the compiler flag too for older versions of FreeBSD. If you can access http://www.cnn.com after this change, but not before, it should work over here too. --HPS
cnn.com loads fine here, it's youtube.com which crashes while trying to autoplay an ad. This stops after rebuilding with attachment 176747 [details]. Here's the 2nd part forgotten in comment 9: (gdb) info reg rax 0x3 3 rbx 0x7ffffc5c15d0 140737427281360 rcx 0x7ffffc5c15d0 140737427281360 rdx 0x7ffffc5c1610 140737427281424 rsi 0x500 1280 rdi 0x82e68c060 35138355296 rbp 0x82f9a0020 0x82f9a0020 rsp 0x7ffffc5c13d8 0x7ffffc5c13d8 r8 0x37 55 r9 0x3 3 r10 0x0 0 r11 0x0 0 r12 0x0 0 r13 0x82f9a0020 35158360096 r14 0x3 3 r15 0x500 1280 rip 0x82b3b2330 0x82b3b2330 <ff_vp9_ipred_dc_left_32x32_avx2> eflags 0x10212 [ AF IF RF ] cs 0x43 67 ss 0x3b 59 ds <unavailable> es <unavailable> fs <unavailable> gs <unavailable>
A commit references this bug: Author: jbeich Date: Mon Nov 7 17:46:39 UTC 2016 New revision: 425640 URL: https://svnweb.freebsd.org/changeset/ports/425640 Log: multimedia/ffmpeg: switch to clang on 9.x It turns out the following is true for ffvp9 on amd64: WARNING: gcc 4.2 is outdated and may miscompile FFmpeg. Please use a newer compiler. PR: 213706 Approved by: portmgr blanket Changes: head/multimedia/ffmpeg/Makefile
Reopen if your issue was different after testing the binary package in a few days. Curiously, multimedia/libav built by GCC 4.2.1 (patched) doesn't crash nor produce such a warning during build.
multimedia/ffmpeg also crashed on 9.x i386 if built with MMX=on + SSE=on.
A commit references this bug: Author: jbeich Date: Mon Nov 7 18:07:51 UTC 2016 New revision: 425641 URL: https://svnweb.freebsd.org/changeset/ports/425641 Log: MFH: r425640 multimedia/ffmpeg: switch to clang on 9.x It turns out the following is true for ffvp9 on amd64: WARNING: gcc 4.2 is outdated and may miscompile FFmpeg. Please use a newer compiler. PR: 213706 Approved by: portmgr blanket Approved by: ports-secteam blanket Changes: _U branches/2016Q4/ branches/2016Q4/multimedia/ffmpeg/Makefile
Another alignment issue was fixed in ports r425733. Not linked here because Hans never provided useful stacktrace to help distinguish.
Recompiling multimedia/ffmpeg with MMX/SSE disabled also works around the issue. That'll do for now. Thanks!