I get bus errors in libffmeg when running inside Chrome. Core was generated by `chrome'. Program terminated with signal 10, Bus error. #0 0x309fa3e2 in ff_deblock_v_luma_8_sse2 () from /usr/local/share/chromium/libffmpegsumo.so (gdb) bt #0 0x309fa3e2 in ff_deblock_v_luma_8_sse2 () from /usr/local/share/chromium/libffmpegsumo.so #1 0xffffffff in ?? () #2 0x308aa2b1 in ?? () from /usr/local/share/chromium/libffmpegsumo.so #3 0x308929f5 in ?? () from /usr/local/share/chromium/libffmpegsumo.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) disassemble 0x309fa3e2 .. .. 0x309fa3e0 <+32>: add %eax,%esi => 0x309fa3e2 <+34>: movdqa (%esi,%ecx,1),%xmm0 0x309fa3e7 <+39>: movdqa (%esi,%ecx,2),%xmm1 0x309fa3ec <+44>: movdqa (%eax),%xmm2 0x309fa3f0 <+48>: movdqa (%eax,%ecx,1),%xmm3 (gdb) info all-registers eax 0xbf4d65c8 -1085446712 ecx 0x10 16 edx 0x7 7 ebx 0x2 2 esp 0xbf4d6548 0xbf4d6548 ebp 0xbf4d66cc 0xbf4d66cc esi 0xbf4d6598 -1085446760 edi 0x380 896 eip 0x309fa3e2 0x309fa3e2 <ff_deblock_v_luma_8_sse2+34> eflags 0x210283 [ CF SF IF RF ID ] cs 0x33 51 ss 0x3b 59 ds 0xbfbf003b -1078001605 es 0x3b 59 fs 0xbfbf003b -1078001605 gs 0x1b 27 st0 -nan(0x2222222222222222) (raw 0xffff2222222222222222) st1 -nan(0x2323232323232323) (raw 0xffff2323232323232323) st2 -nan(0x2424242423232323) (raw 0xffff2424242423232323) st3 -nan(0x2424242424242424) (raw 0xffff2424242424242424) st4 -nan(0x202020201f1f1f1f) (raw 0xffff202020201f1f1f1f) st5 -nan(0x2222222222222222) (raw 0xffff2222222222222222) st6 -nan(0x2222222222222222) (raw 0xffff2222222222222222) st7 -nan(0x2222222222222222) (raw 0xffff2222222222222222) fctrl 0x127f 4735 fstat 0x20 32 ftag 0xaaff 43775 fiseg 0x33 51 fioff 0x309d253b 815605051 foseg 0x3b 59 fooff 0xbf4d6abc -1085445444 fop 0x59c 1436 xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = { 0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = { 0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = { 0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = { 0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = { 0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = { 0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = { 0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = { 0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} mxcsr 0x1f80 [ IM DM ZM OM UM PM ] mm0 {uint64 = 0x2222222222222222, v2_int32 = {0x22222222, 0x22222222}, v4_int16 = {0x2222, 0x2222, 0x2222, 0x2222}, v8_int8 = {0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22}} mm1 {uint64 = 0x2323232323232323, v2_int32 = {0x23232323, 0x23232323}, v4_int16 = {0x2323, 0x2323, 0x2323, 0x2323}, v8_int8 = {0x23, 0x23, 0x23, 0x23, 0x23, 0x23, ---Type <return> to continue, or q <return> to quit--- 0x23, 0x23}} mm2 {uint64 = 0x2424242423232323, v2_int32 = {0x23232323, 0x24242424}, v4_int16 = {0x2323, 0x2323, 0x2424, 0x2424}, v8_int8 = {0x23, 0x23, 0x23, 0x23, 0x24, 0x24, 0x24, 0x24}} mm3 {uint64 = 0x2424242424242424, v2_int32 = {0x24242424, 0x24242424}, v4_int16 = {0x2424, 0x2424, 0x2424, 0x2424}, v8_int8 = {0x24, 0x24, 0x24, 0x24, 0x24, 0x24, 0x24, 0x24}} mm4 {uint64 = 0x202020201f1f1f1f, v2_int32 = {0x1f1f1f1f, 0x20202020}, v4_int16 = {0x1f1f, 0x1f1f, 0x2020, 0x2020}, v8_int8 = {0x1f, 0x1f, 0x1f, 0x1f, 0x20, 0x20, 0x20, 0x20}} mm5 {uint64 = 0x2222222222222222, v2_int32 = {0x22222222, 0x22222222}, v4_int16 = {0x2222, 0x2222, 0x2222, 0x2222}, v8_int8 = {0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22}} mm6 {uint64 = 0x2222222222222222, v2_int32 = {0x22222222, 0x22222222}, v4_int16 = {0x2222, 0x2222, 0x2222, 0x2222}, v8_int8 = {0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22}} mm7 {uint64 = 0x2222222222222222, v2_int32 = {0x22222222, 0x22222222}, v4_int16 = {0x2222, 0x2222, 0x2222, 0x2222}, v8_int8 = {0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22}} . there's data at the given offset: (gdb) x/32x $esi 0xbf4d6598: 0x2022201c 0x21212121 0x20202020 0x20202020 0xbf4d65a8: 0x2225221e 0x24242424 0x23232323 0x23232323 0xbf4d65b8: 0x2326241f 0x25252525 0x24242424 0x24242424 0xbf4d65c8: 0x2224221e 0x23232323 0x22222222 0x22222222 0xbf4d65d8: 0x2224221e 0x23232323 0x22222222 0x22222222 0xbf4d65e8: 0x2224221e 0x23232323 0x22222222 0x22222222 0xbf4d65f8: 0x00000000 0x3f0c9000 0x30a6cfac 0x308b5088 0xbf4d6608: 0x3f21e814 0x00000380 0x00000008 0x00000003 . however it looks like the source address isn't double quadword aligned. So, what gives? Fix: .. I'm not sure if it's a compiler generation bug or a dumb-source code bug. How-To-Repeat: Chrome; look at any news sites full of embedded video crap.
Responsible Changed From-To: freebsd-bugs->freebsd-ports-bugs ports PR.
Responsible Changed From-To: freebsd-ports-bugs->freebsd-chromium Over to maintainer (via the GNATS Auto Assign Tool)
Hi, NetBSD has already found and fixed this. They added an explicit stack alignment set to chromium and mplayer. i386 doesn't have a 16 byte default stack alignment requirement and it's screwing things up. It's likely worth adding this to chromium, mplayer-* ports, libffmeg and firefox. http://gnats.netbsd.org/47132 Would someone please evaluate this? Thanks, -a
A commit references this bug: Author: rene Date: Sun Jun 22 20:35:15 UTC 2014 New revision: 358825 URL: http://svnweb.freebsd.org/changeset/ports/358825 Log: Fix a crash which happens frequently on i386 due to unaligned memory access in its built-in ffmpeg. PR: 189317 Submitted by: dim, adrian on freebsd-chromium@ MFH: 2014Q2 Changes: head/www/chromium/Makefile head/www/chromium/files/patch-third_party__ffmpeg__chromium__config__Chromium__linux__ia32__config.h
I just committed r358825 for this, can you confirm it works now?
A commit references this bug: Author: rene Date: Sun Jun 22 22:19:53 UTC 2014 New revision: 358850 URL: http://svnweb.freebsd.org/changeset/ports/358850 Log: MFH: r358825 Fix a crash which happens frequently on i386 due to unaligned memory access in its built-in ffmpeg. PR: 189317 Submitted by: dim, adrian on freebsd-chromium@ Approved by: portmgr (erwin) Changes: _U branches/2014Q2/ branches/2014Q2/www/chromium/Makefile branches/2014Q2/www/chromium/files/patch-third_party__ffmpeg__chromium__config__Chromium__linux__ia32__config.h
This is supposedly fixed by upstream, so the patch is not needed anymore.