Bug 242147 - multimedia/ffmpeg: Illegal instruction on i586
Summary: multimedia/ffmpeg: Illegal instruction on i586
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: i386 Any
: --- Affects Some People
Assignee: freebsd-multimedia (Nobody)
URL:
Keywords: regression
Depends on:
Blocks: 210505
  Show dependency treegraph
 
Reported: 2019-11-21 20:35 UTC by jose1711
Modified: 2021-04-16 19:17 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (multimedia)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jose1711 2019-11-21 20:35:21 UTC
ffmpeg is crashing on my slightly less common i586-based system (https://en.wikipedia.org/wiki/Vortex86).

$ ffmpeg
Illegal instruction

Coredump is generated. The cure was recompiling ffmpeg from ports with OpenCV disabled. Until a proper fix is found I wish OpenCV is disabled in binary package as it takes several hours to compile ffmpeg and all its dependencies though.

freebsd-version = 12.1-RELEASE-p1
Comment 1 Tatsuki Makino 2019-11-22 05:57:17 UTC
I have an environment that can do the same thing.
12.1-STABLE r354763M i386

> ffmpeg 
Illegal instruction (core dumped)
Exit 132

I don't know how to use lldb :)

(lldb) bt
* thread #1, name = 'ffmpeg', stop reason = signal SIGILL
  * frame #0: 0x22465bb1 libopencv_core.so.3.4`cvRegisterType + 609
    frame #1: 0x22472daa libopencv_core.so.3.4`___lldb_unnamed_symbol1029$$libopencv_core.so.3.4 + 154
    frame #2: 0x2043d445 ld-elf.so.1
    frame #3: 0x2043c436 ld-elf.so.1
Comment 2 jose1711 2019-11-25 12:43:55 UTC
@tatsuki

Can you please share details about your processor? I wonder if it's something exotic as it is in my case. Thanks!
Comment 3 Tatsuki Makino 2019-11-25 22:45:26 UTC
(In reply to jose1711 from comment #2)
I forgot to write it :)

sysctl -n hw.model returns "Intel Pentium III" in my environment.
To be precise, Intel® Pentium® III Processor 1GHz (133MHz FSB) and i810E chipset.

So, this is not just a special SoC, but a problem for the entire i386.
Comment 4 Jan Beich freebsd_committer freebsd_triage 2019-11-25 23:57:21 UTC
Likely a regression from options refactor in graphics/opencv which makes i386 use -msse -msse2 -mfpmath=sse on all files. For runtime detection to work only functions (or files) that use SSE2 instructions should be built with -msse2, letting the caller check CPU features and decide whether to use optimized functions. If the caller is built with -msse2 you get a crash on pre-SSE2 hardware. Unfortunately, upstream checks SSE2 support at compile time.

https://github.com/opencv/opencv/search?q=checkHardwareSupport
https://github.com/opencv/opencv/blob/3.4.1/cmake/OpenCVCompilerOptimizations.cmake#L71

While the following may help

  # OpenCV minimum SIMD without runtime detection
  CMAKE_ARGS+=	${CMAKE_ARGS_${ARCH}}
  CMAKE_ARGS_amd64=-DCPU_BASELINE_DISABLE:STRING=SSE3
  CMAKE_ARGS_i386=-DCPU_BASELINE_DISABLE:STRING=SSE

it breaks building SIMD-optimized code

  FAILED: modules/core/CMakeFiles/opencv_core.dir/mathfuncs_core.avx.cpp.o 
  /usr/bin/c++  -DCVAPI_EXPORTS -D_USE_MATH_DEFINES -D__OPENCV_BUILD=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DCV_CPU_COMPILE_AVX=1 -DCV_CPU_COMPILE_POPCNT=1 -DCV_CPU_COMPILE_SSE2=1 -DCV_CPU_COMPILE_SSE3=1 -DCV_CPU_COMPILE_SSE4_1=1 -DCV_CPU_COMPILE_SSE4_2=1 -DCV_CPU_COMPILE_SSE=1 -DCV_CPU_COMPILE_SSSE3=1 -DCV_CPU_DISPATCH_MODE=AVX -I/wrkdirs/usr/ports/graphics/opencv-core/work/opencv-3.4.1/modules/core/include -I/wrkdirs/usr/ports/graphics/opencv-core/work/opencv-3.4.1/modules/core/src -Imodules/core -isystem . -isystem /usr/local/include/eigen3 -O2 -pipe  -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing   -isystem /usr/local/include -std=c++11   -fsigned-char -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized -Winit-self -Wno-narrowing -Wno-delete-non-virtual-dtor -Wno-unnamed-type-template-args -Wno-comment -Wno-implicit-fallthrough -fdiagnostics-show-option -pthread -Qunused-arguments -fomit-frame-pointer -ffunction-sections -fdata-sections  -mfpmath=387 -fvisibility=hidden -fvisibility-inlines-hidden -O2 -pipe  -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing   -isystem /usr/local/include -std=c++11  -DNDEBUG -fPIC   -std=c++11  -msse -msse2 -msse3 -mssse3 -msse4.1 -mpopcnt -msse4.2 -mavx -MD -MT modules/core/CMakeFiles/opencv_core.dir/mathfuncs_core.avx.cpp.o -MF modules/core/CMakeFiles/opencv_core.dir/mathfuncs_core.avx.cpp.o.d -o modules/core/CMakeFiles/opencv_core.dir/mathfuncs_core.avx.cpp.o -c modules/core/mathfuncs_core.avx.cpp
  error: the '387' unit is not supported with this instruction set
Comment 5 Thomas Zander freebsd_committer freebsd_triage 2021-04-16 19:17:13 UTC
Please reopen if this is still an issue.