OS: FreeBSD 14.1 amd64. CPU: Core 2 Quad Q6600. Build OpenJPH 0.17.0 from ports without -march and with -march=core2 - same result. Dependencies list: smplayer => qt5 => kf5-kimageformats => libheif => OpenJPH. $ gdb smplayer GNU gdb (GDB) 15.1 [GDB v15.1 for FreeBSD] Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.1". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from smplayer... (No debugging symbols found in smplayer) (gdb) run Starting program: /usr/local/bin/smplayer [New LWP 807958 of process 16273] Qt: Session management error: None of the authentication protocols specified are supported [New LWP 807959 of process 16273] This is SMPlayer v. 24.5.0 (revision 10277) running on FreeBSD [New LWP 807960 of process 16273] [Detaching after fork from child process 16274] Thread 1 received signal SIGILL, Illegal instruction. Privileged opcode. 0x000000081576a81a in ojph::local::initialize_tables_avx2() () from /usr/local/lib/libopenjph.so.0.17 $ valgrind smplayer ... vex amd64->IR: unhandled instruction bytes: 0xC5 0xF8 0x77 0xC3 0xC5 0xF8 0x77 0xE8 0xDA 0x64 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==16247== valgrind: Unrecognised instruction at address 0x1b5f881a. ==16247== at 0x1B5F881A: ojph::local::initialize_tables_avx2() (in /usr/local/lib/libopenjph.so.0.17.0) ==16247== by 0x400AF5C: ??? (in /libexec/ld-elf.so.1) ==16247== by 0x400F3F2: ??? (in /libexec/ld-elf.so.1) ==16247== by 0x400BF52: ??? (in /libexec/ld-elf.so.1) ==16247== by 0x12D32276: ??? (in /usr/local/lib/libheif.so.1.19.1) ==16247== by 0x12CBCB3B: heif_load_plugin (in /usr/local/lib/libheif.so.1.19.1) ==16247== by 0x12CBC7DE: heif_load_plugins (in /usr/local/lib/libheif.so.1.19.1) ==16247== by 0x12CBC5DE: heif_init (in /usr/local/lib/libheif.so.1.19.1) ==16247== by 0x12C1CADA: ??? (in /usr/local/lib/qt5/plugins/imageformats/kimg_heif.so) ==16247== by 0x12C1CCD9: ??? (in /usr/local/lib/qt5/plugins/imageformats/kimg_heif.so) ==16247== by 0x532D72F: ??? (in /usr/local/lib/qt5/libQt5Gui.so.5.15.15) ==16247== by 0x532A4DF: QImageReader::supportedImageFormats() (in /usr/local/lib/qt5/libQt5Gui.so.5.15.15) ==16247== Your program just tried to execute an instruction that Valgrind ==16247== did not recognise. There are two possible reasons for this. ==16247== 1. Your program has a bug and erroneously jumped to a non-code ==16247== location. If you are running Memcheck and you just saw a ==16247== warning about a bad jump, it's probably your program's fault. ==16247== 2. The instruction is legitimate but Valgrind doesn't handle it, ==16247== i.e. it's Valgrind's fault. If you think this is the case or ==16247== you are not sure, please let us know and we'll try to fix it. ==16247== Either way, Valgrind will now raise a SIGILL signal which will ==16247== probably kill your program. ==16247== ==16247== Process terminating with default action of signal 4 (SIGILL): dumping core ==16247== Illegal opcode at address 0x1B5F881A ==16247== at 0x1B5F881A: ojph::local::initialize_tables_avx2() (in /usr/local/lib/libopenjph.so.0.17.0) ==16247== by 0x400AF5C: ??? (in /libexec/ld-elf.so.1) ==16247== by 0x400F3F2: ??? (in /libexec/ld-elf.so.1) ==16247== by 0x400BF52: ??? (in /libexec/ld-elf.so.1) ==16247== by 0x12D32276: ??? (in /usr/local/lib/libheif.so.1.19.1) ==16247== by 0x12CBCB3B: heif_load_plugin (in /usr/local/lib/libheif.so.1.19.1) ==16247== by 0x12CBC7DE: heif_load_plugins (in /usr/local/lib/libheif.so.1.19.1) ==16247== by 0x12CBC5DE: heif_init (in /usr/local/lib/libheif.so.1.19.1) ==16247== by 0x12C1CADA: ??? (in /usr/local/lib/qt5/plugins/imageformats/kimg_heif.so) ==16247== by 0x12C1CCD9: ??? (in /usr/local/lib/qt5/plugins/imageformats/kimg_heif.so) ==16247== by 0x532D72F: ??? (in /usr/local/lib/qt5/libQt5Gui.so.5.15.15) ==16247== by 0x532A4DF: QImageReader::supportedImageFormats() (in /usr/local/lib/qt5/libQt5Gui.so.5.15.15) ... AFAIU: 0xC5 0xF8 0x77 = vzeroupper from AVX. https://fuchsia.googlesource.com/third_party/llvm-project/+/refs/tags/llvmorg-13.0.0-rc1/llvm/test/CodeGen/X86/fma.ll?autodive=0%2F%2F%2F%2F%2F%2F%2F%2F#665 https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#New_instructions Runtime detection of supported SIMD level in init_cpu_ext_level() work well, but OpenJPH still use instructions from unsupported SIMDs on current CPU. There are build options: option(OJPH_DISABLE_SIMD "Disables the use of SIMD instructions -- agnostic to architectures" OFF) option(OJPH_DISABLE_SSE "Disables the use of SSE SIMD instructions and associated files" OFF) option(OJPH_DISABLE_SSE2 "Disables the use of SSE2 SIMD instructions and associated files" OFF) option(OJPH_DISABLE_SSSE3 "Disables the use of SSSE3 SIMD instructions and associated files" OFF) option(OJPH_DISABLE_SSE4 "Disables the use of SSE4 SIMD instructions and associated files" OFF) option(OJPH_DISABLE_AVX "Disables the use of AVX SIMD instructions and associated files" OFF) option(OJPH_DISABLE_AVX2 "Disables the use of AVX2 SIMD instructions and associated files" OFF) option(OJPH_DISABLE_AVX512 "Disables the use of AVX512 SIMD instructions and associated files" OFF) option(OJPH_DISABLE_NEON "Disables the use of NEON SIMD instructions and associated files" OFF) If I build with: CMAKE_ON=OJPH_DISABLE_SSE4 OJPH_DISABLE_AVX OJPH_DISABLE_AVX2 OJPH_DISABLE_AVX512 then smplayer run and work fine. Upstream issue: https://github.com/aous72/OpenJPH/issues/157 I can create (trivial) patch with all SIMD options for amd64. With default ON OJPH_DISABLE_SSE and OJPH_DISABLE_SSE2 only.
I have this same issue, also on a Core 2 Quad Q660, that is causing all plasma applications (including sddm-greeter) to fail with signal 4. Building this port using WITH_DEBUG=yes, which probably disabled optimizations, allows the apps to work.
Created attachment 255044 [details] add AVX knob enable by default Was just about to post this patch, wish I had found this sooner then KDE just no longer worker, and going through rebuilding it assuming something introduced a binary incompatibility on my live system. anyway, verified this resolves my issue, upstream enables all SIMD instructions by default so they have to be explicitly turned off. Not sure if it should be on or off by default, I left on as that was how the port is going to be in the repo now, and the general trend from what I've seen.
(In reply to alt2600 from comment #2) What about SSE4?
Upstream fixed this issue today in version 0.18.0. Patch for update port is trivial - just change version in Makefile, run make makesum and update pkg-plist. But "I don't like" SONAME "libopenjph.so.0.18" instead "libopenjph.so.0" - bump consumers every release. The patch suggested to upstream.
(In reply to Vladimir Druzenko from comment #3) in my case its only ever been AVX that is an issue running a westmere. and as you pointed out below upstream considers things to be self dispatching, so it will check runtime for supported features and not use illegal instructions on an arch. that seemed to be broken, at least with llvm possibly gcc if I read the upstream bug report correctly. but i concede, I had a patch done and was about to put in a report to add AVX knob, and given how easy it would be to add SSE even selectively I didn't change my patch. more knobs could be added, or hopefully the runtime dispatch is fixed upstream and this is all moot as your next comment suggests it should be.
Created attachment 255118 [details] Update 0.17.0 → 0.18.0 with fix using AVX My case fixed with this patch.
Po-Chuan Hsieh, I can commit this self if you want.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=9c6fd40d482673376f211b0e32d1747450fb7dfb commit 9c6fd40d482673376f211b0e32d1747450fb7dfb Author: Baptiste Daroussin <bapt@FreeBSD.org> AuthorDate: 2024-11-12 16:45:17 +0000 Commit: Baptiste Daroussin <bapt@FreeBSD.org> CommitDate: 2024-11-12 16:45:17 +0000 graphics/libheif: chase upgrade of openjph PR: 282543 graphics/libheif/Makefile | 1 + 1 file changed, 1 insertion(+)
Fixed in: https://cgit.freebsd.org/ports/commit/?id=1876b07e4fcf269a1c57ac401ab57e4337bcf465