This has happened to me today, for the first time, after a two-week delayed system update with "emerge --update --newuse --changed-use --newrepo --ask -vt --deep --complete-graph=y --changed-deps=y --with-bdeps=y @world" (lots of kde/plasma/rocm/other stuff updated): ------------ user@box ~ $ darktable Violación de segmento (`core' generado) user@box ~ $ darktable --disable-opencl (darktable:151461): Gtk-WARNING **: 18:11:27.876: Theme directory panel/22 of theme Mojave-CT-Night has no size field (darktable:151461): Gtk-WARNING **: 18:11:31.963: Theme directory panel/22 of theme Mojave-CT-Night has no size field [rawspeed] (_A010240.ORF) rawspeed::RawImage rawspeed::RawDecoder::decodeRaw(), line 277: const uint8_t* rawspeed::BitStream<Tag, Cache>::getInput() [with Tag = rawspeed::MSBBitPumpTag; Cache = rawspeed::BitStreamCacheRightInLeftOut; uint8_t = unsigned char], line 139: Buffer overflow read in BitStream [dt_imageio_export_with_flags] mipmap allocation for `unused' failed ----------- As you can see, launching darktable with opencl enabled causes a segfault. I've tried re-emerging darktable after also re-emerging sys-devel/llvm-roc, sys-devel/llvm-common, sys-devel/llvm, dev-util/opencl-headers, dev-libs/rocm-opencl-runtime and virtual/opencl, to no avail. I had never before experienced this behavior. My emerge info: ----- Portage 3.0.17 (python 3.8.8-final-0, default/linux/amd64/17.1/desktop/plasma/systemd, gcc-10.2.0, glibc-2.32-r7, 5.10.27-gentoo x86_64) ================================================================= System uname: Linux-5.10.27-gentoo-x86_64-AMD_Ryzen_7_3700X_8-Core_Processor-with-glibc2.2.5 KiB Mem: 32871828 total, 17870728 free KiB Swap: 33554428 total, 33554428 free Timestamp of repository gentoo: Tue, 13 Apr 2021 06:00:01 +0000 Head commit of repository gentoo: 5df1e7b0c8d3515c66dd045842e11adc076cb629 Timestamp of repository 4nykey: Mon, 12 Apr 2021 10:36:22 +0000 Head commit of repository 4nykey: 120218e0c39505da3b3967c9693167fefb2038b5 Timestamp of repository brave-overlay: Mon, 12 Apr 2021 01:22:58 +0000 Head commit of repository brave-overlay: cd2e148835edd885368665c00386d3f06fceed16 Timestamp of repository fol4: Mon, 12 Apr 2021 10:36:28 +0000 Head commit of repository fol4: 792dc904014da4b303199ab3087d4cf8a2d8c8ee Timestamp of repository torbrowser: Mon, 12 Apr 2021 10:36:12 +0000 Head commit of repository torbrowser: c7c36cb13974f69e9d6b4bdb81fcccc9950b6189 sh bash 5.0_p18 ld GNU ld (Gentoo 2.35.2 p1) 2.35.2 app-shells/bash: 5.0_p18::gentoo dev-java/java-config: 2.3.1::gentoo dev-lang/perl: 5.30.3::gentoo dev-lang/python: 3.8.8_p1::gentoo, 3.9.2_p1::gentoo dev-lang/rust-bin: 1.47.0-r1::gentoo dev-util/cmake: 3.18.5::gentoo sys-apps/baselayout: 2.7::gentoo sys-apps/sandbox: 2.20::gentoo sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r5::gentoo sys-devel/automake: 1.16.2-r1::gentoo sys-devel/binutils: 2.35.2::gentoo sys-devel/gcc: 10.2.0-r5::gentoo sys-devel/gcc-config: 2.3.3::gentoo sys-devel/libtool: 2.4.6-r6::gentoo sys-devel/make: 4.3::gentoo sys-kernel/linux-headers: 5.10::gentoo (virtual/os-headers) sys-libs/glibc: 2.32-r7::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 sync-rsync-verify-metamanifest: yes sync-rsync-extra-opts: sync-rsync-verify-jobs: 1 sync-rsync-verify-max-age: 24 4nykey location: /var/db/repos/4nykey sync-type: git sync-uri: https://github.com/gentoo-mirror/4nykey.git masters: gentoo brave-overlay location: /var/db/repos/brave-overlay sync-type: git sync-uri: https://github.com/gentoo-mirror/brave-overlay.git masters: gentoo fol4 location: /var/db/repos/fol4 sync-type: git sync-uri: https://github.com/gentoo-mirror/fol4.git masters: gentoo local location: /var/db/repos/local masters: gentoo priority: 0 torbrowser location: /var/db/repos/torbrowser sync-type: git sync-uri: https://github.com/gentoo-mirror/torbrowser.git masters: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=znver2 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/cxoffice/etc/cxoffice.conf /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=znver2 -O2 -pipe" DISTDIR="/var/cache/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-march=znver2 -O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-march=znver2 -O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" INSTALL_MASK="/usr/share/locale -/usr/share/locale/es -/usr/share/locale/es_ES -/usr/share/locale/en_US -/usr/share/locale/en /usr/share/gcc-data/x86_64-pc-linux-gnu/*/locale -/usr/share/gcc-data/x86_64-pc-linux-gnu/*/locale/es /usr/share/man/de /usr/share/man/el /usr/share/man/fr /usr/share/man/hu /usr/share/man/ja /usr/share/man/jp /usr/share/man/sk /usr/share/man/zh_TW" LANG="es_ES.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="es_ES es en_US en" MAKEOPTS="-j16" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac aalib acl acpi activities alsa amd64 amr atm berkdb bluetooth branding btrfs bzip2 cairo cdda cddb cdr cli contrib crypt cups curl daemon dbus declarative dga djvu dri dts dv dvd dvdr emboss encode exif fbcon ffmpeg fftw flac fontconfig fortran ftp fuse gdbm geolocation gif gimp gmp gnome-keyring gphoto2 gpm grub gstreamer gtk gui iconv icu idn imagemagick imlib ipv6 jack java jbig jpeg jpeg2k kde kipi kwallet lame lapack latex lcms libass libcaca libglvnd libkms libnotify libtirpc lm-sensors lzma lzo mad mmap mng modplug mono mp3 mp4 mpeg mtp multilib musepack nas ncurses network networkmanager nls nptl ogg openal opencl openexr opengl openmp oss pam pango pcre pdf phonon pkcs11 plasma png policykit portaudio postscript ppds qml qt5 rar raw readline ruby samba sasl scanner sdl seccomp semantic-desktop slang smartcard spell split-usr ssl startup-notification svg syslog systemd taglib tcl tcpd theora threads tiff tk truetype twolame udev udisks unicode upnp upower usb v4l vaapi vcd vdpau vnc vorbis wavpack wayland widgets wmf wxwidgets x264 xattr xcb xml xmp xv xvid zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="hda-intel" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon krita" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2 aes avx avx2 f16c fma3 pclmul popcnt rdrand sha sse3 sse4_1 sse4_2 sse4a ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="synaptics evdev" KERNEL="linux" L10N="es-ES es en-US en" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_8" PYTHON_TARGETS="python3_8" RUBY_TARGETS="ruby26" SANE_BACKENDS="epson2 hp" USERLAND="GNU" VIDEO_CARDS="radeonsi amdgpu" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RUSTFLAGS
I use a Radeon RX 580 card/Ryzen 7 3700X CPU. These are the opencl packages I use: ----- $ eix -I opencl [I] dev-libs/rocm-opencl-runtime Available versions: (~)3.8.0(0/3.8) (~)3.9.0(0/3.9) (~)3.10.0(0/3.10) (~)4.0.0(0/4.0) (~)4.1.0(0/4.1) Installed versions: 4.1.0(0/4.1)(14:11:53 13/04/21) Homepage: https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime Description: Radeon Open Compute OpenCL Compatible Runtime [I] dev-util/opencl-headers Available versions: 2020.03.13-r1 2020.06.16 ~2020.12.18 Installed versions: 2020.06.16(14:11:39 13/04/21) Homepage: https://github.com/KhronosGroup/OpenCL-Headers Description: Unified C language headers for the OpenCL API [I] virtual/opencl Available versions: 3-r1 {ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32"} Installed versions: 3-r1(13:41:43 13/04/21)(ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="32 64 -x32") Description: Virtual for OpenCL API Found 3 matches
Would be helpful if could figure out what upgrade triggered the issue, I'd assume it's not darktable itself since 3.4.1 was added 2 months ago. The various roc* packages however were upgraded to 4.1.0 under 2 weeks ago. Not familiar with those myself (no AMD hardware to test), but could attempt a downgrade. Something like this so they match (may need adjustment): emerge -1 dev-libs/rocclr:0/4.0 \ dev-libs/rocm-comgr:0/4.0 \ dev-libs/rocm-device-libs:0/4.0 \ dev-libs/rocm-opencl-runtime:0/4.0 \ dev-libs/rocr-runtime:0/4.0 A backtrace could give some hints as well: https://wiki.gentoo.org/wiki/Debugging_with_GDB
Thanks for your help. I'm gonna downgrade all my roc* packages: ----- These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild UD~] dev-util/rocminfo-4.0.0:0/4.0::gentoo [4.1.0:0/4.1::gentoo] 15 KiB [ebuild UD~] dev-libs/rocm-opencl-runtime-4.0.0:0/4.0::gentoo [4.1.0:0/4.1::gentoo] 981 KiB [ebuild UD~] dev-libs/rocclr-4.0.0:0/4.0::gentoo [4.1.0:0/4.1::gentoo] 795 KiB [ebuild UD~] dev-libs/rocm-comgr-4.0.0:0/4.0::gentoo [4.1.0:0/4.1::gentoo] 97 KiB [ebuild UD~] dev-libs/rocr-runtime-4.0.0:0/4.0::gentoo [4.1.0:0/4.1::gentoo] USE="(-debug%)" 676 KiB [ebuild UD~] dev-libs/rocm-device-libs-4.0.0:0/4.0::gentoo [4.1.0:0/4.1::gentoo] 226 KiB [ebuild UD~] sys-devel/llvm-roc-4.0.0::gentoo [4.1.1::gentoo] USE="-debug -runtime*" 120.700 KiB [ebuild UD~] dev-libs/roct-thunk-interface-4.0.0:0/4.0::gentoo [4.1.0:0/4.1::gentoo] 2.631 KiB [ebuild UD~] dev-util/rocm-cmake-4.0.0::gentoo [4.1.0::gentoo] 16 KiB Total: 9 packages (9 downgrades), Size of downloads: 126.133 KiB ----- However, I see sys-devel/llvm-roc-4.1 has the "runtime" USE flag enabled by default, whilst this flag is not enabled for the v4.0. Might that be the reason? Anyway, when the emerge process finishes, we'll know if any of the newer v4.1 roc* packages is the culprit.
OK. After emerging the v4.0 roc* packages above, darktable launches fine. Now, I'm gonna upgrade them again to the v4.1 but disabling the USE="runtime" for sys-devel/llvm-roc.
(In reply to urcindalo from comment #4) > Now, I'm gonna upgrade them again to the v4.1 but disabling the > USE="runtime" for sys-devel/llvm-roc. Nope. No luck. Not even with USE="-runtime" does it work: segfault. The issue lies somewhere in the v4.1 roc* packages. When I got the time I'll try the backtrace route.
(In reply to urcindalo from comment #5) > When I got the time I'll try the backtrace route. Here are the debugging results: ----- $ gdb --args darktable GNU gdb (Gentoo 10.1 vanilla) 10.1 Copyright (C) 2020 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-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. 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 darktable... (gdb) run Starting program: /usr/bin/darktable [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff0b59640 (LWP 351217)] [New Thread 0x7fffebfff640 (LWP 351218)] [New Thread 0x7fffeb7fe640 (LWP 351219)] [Detaching after fork from child process 351220] [New Thread 0x7fffeaffd640 (LWP 351221)] [New Thread 0x7fffea3df640 (LWP 351222)] [New Thread 0x7fffe9bde640 (LWP 351223)] [New Thread 0x7fffe93dd640 (LWP 351224)] [New Thread 0x7fffe8bdc640 (LWP 351225)] [New Thread 0x7fffcbfff640 (LWP 351226)] [New Thread 0x7fffcb7fe640 (LWP 351227)] [New Thread 0x7fffcaffd640 (LWP 351228)] [New Thread 0x7fffca7fc640 (LWP 351229)] [New Thread 0x7fffc9ffb640 (LWP 351230)] [New Thread 0x7fffc97fa640 (LWP 351231)] [New Thread 0x7fffc8ff9640 (LWP 351232)] [New Thread 0x7fffb3fff640 (LWP 351233)] [New Thread 0x7fffb37fe640 (LWP 351234)] [New Thread 0x7fffb28f4640 (LWP 351238)] [New Thread 0x7fffb1fb2640 (LWP 351239)] [New Thread 0x7fffb17b1640 (LWP 351240)] [New Thread 0x7fffb0fb0640 (LWP 351241)] [New Thread 0x7fffa116a640 (LWP 351242)] [New Thread 0x7fffa0969640 (LWP 351243)] [New Thread 0x7fff8bfff640 (LWP 351244)] [New Thread 0x7fff8b7fe640 (LWP 351245)] [New Thread 0x7fff8affd640 (LWP 351246)] [New Thread 0x7fff8a7fc640 (LWP 351247)] [New Thread 0x7fff89ffb640 (LWP 351248)] [New Thread 0x7fff897fa640 (LWP 351249)] [New Thread 0x7fff88ff9640 (LWP 351250)] [New Thread 0x7fff67fff640 (LWP 351251)] [New Thread 0x7fff677fe640 (LWP 351252)] [New Thread 0x7fff66ffd640 (LWP 351253)] [New Thread 0x7fff667fc640 (LWP 351254)] [New Thread 0x7fff65ffb640 (LWP 351255)] [New Thread 0x7fff657fa640 (LWP 351256)] [New Thread 0x7fff64ff9640 (LWP 351257)] [New Thread 0x7fff47fff640 (LWP 351258)] [New Thread 0x7fff477fe640 (LWP 351259)] [New Thread 0x7fff46ffd640 (LWP 351260)] [New Thread 0x7fff467fc640 (LWP 351261)] [New Thread 0x7fff45ffb640 (LWP 351262)] [New Thread 0x7fff457fa640 (LWP 351263)] [New Thread 0x7fff44ff9640 (LWP 351264)] [New Thread 0x7fff27fff640 (LWP 351265)] [New Thread 0x7fff1ffff640 (LWP 351266)] [New Thread 0x7fff277fe640 (LWP 351267)] [New Thread 0x7fff26ffd640 (LWP 351268)] [New Thread 0x7fff267fc640 (LWP 351269)] [New Thread 0x7fff25ffb640 (LWP 351270)] [New Thread 0x7fff257fa640 (LWP 351271)] [New Thread 0x7fff24ff9640 (LWP 351272)] [New Thread 0x7fff1f7fe640 (LWP 351273)] [New Thread 0x7fff1effd640 (LWP 351274)] [New Thread 0x7fff1e7fc640 (LWP 351275)] [New Thread 0x7fff1dffb640 (LWP 351276)] [New Thread 0x7fff1d7fa640 (LWP 351277)] [New Thread 0x7fff1cff9640 (LWP 351278)] [New Thread 0x7ffee7fff640 (LWP 351279)] [New Thread 0x7ffee77fe640 (LWP 351280)] [New Thread 0x7ffee6ffd640 (LWP 351281)] [New Thread 0x7ffee67fc640 (LWP 351282)] [New Thread 0x7ffee5ffb640 (LWP 351283)] [New Thread 0x7ffee57fa640 (LWP 351284)] [New Thread 0x7ffee4ff9640 (LWP 351285)] [New Thread 0x7ffec7fff640 (LWP 351286)] [New Thread 0x7ffec77fe640 (LWP 351287)] [New Thread 0x7ffec6ffd640 (LWP 351288)] [New Thread 0x7ffec67fc640 (LWP 351289)] [New Thread 0x7ffec5ffb640 (LWP 351290)] [New Thread 0x7ffec57fa640 (LWP 351291)] [New Thread 0x7ffec4ff9640 (LWP 351292)] [New Thread 0x7ffea7fff640 (LWP 351293)] [New Thread 0x7ffea77fe640 (LWP 351294)] [New Thread 0x7ffea6ffd640 (LWP 351295)] [Thread 0x7ffec57fa640 (LWP 351291) exited] [Thread 0x7ffec5ffb640 (LWP 351290) exited] [Thread 0x7ffec67fc640 (LWP 351289) exited] [Thread 0x7ffec6ffd640 (LWP 351288) exited] [Thread 0x7ffec77fe640 (LWP 351287) exited] [Thread 0x7ffec7fff640 (LWP 351286) exited] [Thread 0x7ffee4ff9640 (LWP 351285) exited] [Thread 0x7ffee57fa640 (LWP 351284) exited] [Thread 0x7ffee5ffb640 (LWP 351283) exited] [Thread 0x7ffee67fc640 (LWP 351282) exited] [Thread 0x7ffee6ffd640 (LWP 351281) exited] [Thread 0x7ffee77fe640 (LWP 351280) exited] [Thread 0x7ffee7fff640 (LWP 351279) exited] [Thread 0x7fff1cff9640 (LWP 351278) exited] [Thread 0x7fff1d7fa640 (LWP 351277) exited] [Thread 0x7fff1dffb640 (LWP 351276) exited] [Thread 0x7fff1e7fc640 (LWP 351275) exited] [Thread 0x7fff1effd640 (LWP 351274) exited] [Thread 0x7fff1f7fe640 (LWP 351273) exited] [Thread 0x7fff24ff9640 (LWP 351272) exited] [Thread 0x7fff257fa640 (LWP 351271) exited] [Thread 0x7fff25ffb640 (LWP 351270) exited] [Thread 0x7fff267fc640 (LWP 351269) exited] [Thread 0x7fff26ffd640 (LWP 351268) exited] [Thread 0x7fff277fe640 (LWP 351267) exited] [Thread 0x7fff1ffff640 (LWP 351266) exited] [Thread 0x7fff27fff640 (LWP 351265) exited] [Thread 0x7fff44ff9640 (LWP 351264) exited] [Thread 0x7fff457fa640 (LWP 351263) exited] [Thread 0x7fff45ffb640 (LWP 351262) exited] [Thread 0x7fff467fc640 (LWP 351261) exited] [Thread 0x7fff46ffd640 (LWP 351260) exited] [Thread 0x7ffea6ffd640 (LWP 351295) exited] [Thread 0x7ffea77fe640 (LWP 351294) exited] [Thread 0x7ffea7fff640 (LWP 351293) exited] [Thread 0x7ffec4ff9640 (LWP 351292) exited] [New Thread 0x7ffea6ffd640 (LWP 351296)] [New Thread 0x7ffea77fe640 (LWP 351297)] [Thread 0x7ffea77fe640 (LWP 351297) exited] [New Thread 0x7fff25454640 (LWP 351298)] --Type <RET> for more, q to quit, c to continue without paging-- Thread 79 "Command Queue T" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff25454640 (LWP 351298)] 0x00007fffa59c0278 in ?? () from /usr/lib/llvm/11/lib64/libclang-cpp.so.11.1 (gdb) bt #0 0x00007fffa59c0278 in () at /usr/lib/llvm/11/lib64/libclang-cpp.so.11.1 #1 0x00007fffa5d5f363 in clang::FunctionProtoType::Profile(llvm::FoldingSetNodeID&, clang::ASTContext const&) () at /usr/lib/llvm/11/lib64/libclang-cpp.so.11.1 #2 0x00007fffa59bc3da in () at /usr/lib/llvm/11/lib64/libclang-cpp.so.11.1 #3 0x00007fff45845367 in llvm::FoldingSetBase::FindNodeOrInsertPos(llvm::FoldingSetNodeID const&, void*&, llvm::FoldingSetBase::FoldingSetInfo const&) () at /usr/lib/llvm/roc/lib/libLLVMSupport.so.12roc #4 0x00007fff2630c3e5 in clang::ASTContext::getFunctionTypeInternal(clang::QualType, llvm::ArrayRef<clang::QualType>, clang::FunctionProtoType::ExtProtoInfo const&, bool) const () at /usr/lib/llvm/roc/lib/../lib/libclangAST.so.12roc #5 0x00007fff27079fbd in () at /usr/lib/llvm/roc/lib/../lib/libclangSema.so.12roc #6 0x00007fff2707dc26 in clang::Sema::GetTypeForDeclarator(clang::Declarator&, clang::Scope*) () at /usr/lib/llvm/roc/lib/../lib/libclangSema.so.12roc #7 0x00007fff26ab3477 in clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&, llvm::MutableArrayRef<clang::TemplateParameterList*>) () at /usr/lib/llvm/roc/lib/../lib/libclangSema.so.12roc #8 0x00007fff26ab41c4 in clang::Sema::ActOnDeclarator(clang::Scope*, clang::Declarator&) () at /usr/lib/llvm/roc/lib/../lib/libclangSema.so.12roc #9 0x00007fff2721117f in clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) () at /usr/lib/llvm/roc/lib/../lib/libclangParse.so.12roc #10 0x00007fff2721924e in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) () at /usr/lib/llvm/roc/lib/../lib/libclangParse.so.12roc #11 0x00007fff272d1975 in () at /usr/lib/llvm/roc/lib/../lib/libclangParse.so.12roc #12 0x00007fff272d97b0 in clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) () at /usr/lib/llvm/roc/lib/../lib/libclangParse.so.12roc #13 0x00007fff272da608 in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) () at /usr/lib/llvm/roc/lib/../lib/libclangParse.so.12roc #14 0x00007fff27201a09 in clang::ParseAST(clang::Sema&, bool, bool) () at /usr/lib/llvm/roc/lib/../lib/libclangParse.so.12roc #15 0x00007fff881767b9 in clang::FrontendAction::Execute() () at /usr/lib/llvm/roc/lib/libclangFrontend.so.12roc #16 0x00007fff8812914b in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) () at /usr/lib/llvm/roc/lib/libclangFrontend.so.12roc #17 0x00007fffe808b103 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) () at /usr/lib/llvm/roc/lib/libclangFrontendTool.so.12roc #18 0x00007fff466d7c0a in () at /usr/lib64/libamd_comgr.so.2 #19 0x00007fff466d8e89 in () at /usr/lib64/libamd_comgr.so.2 #20 0x00007fff466d949e in () at /usr/lib64/libamd_comgr.so.2 #21 0x00007fff466de86a in () at /usr/lib64/libamd_comgr.so.2 #22 0x00007fff466e2799 in amd_comgr_do_action () at /usr/lib64/libamd_comgr.so.2 #23 0x00007fffe8361755 in () at /usr/lib64/libamdocl64.so #24 0x00007fffe83679e2 in () at /usr/lib64/libamdocl64.so #25 0x00007fffe836a3cd in () at /usr/lib64/libamdocl64.so #26 0x00007fffe8317567 in () at /usr/lib64/libamdocl64.so #27 0x00007fffe8301629 in () at /usr/lib64/libamdocl64.so #28 0x00007fffe833be1f in () at /usr/lib64/libamdocl64.so #29 0x00007fffe8378b78 in () at /usr/lib64/libamdocl64.so #30 0x00007fffe834df5d in () at /usr/lib64/libamdocl64.so #31 0x00007fffe833aaa4 in () at /usr/lib64/libamdocl64.so #32 0x00007fffe831b497 in () at /usr/lib64/libamdocl64.so #33 0x00007fffe82a9630 in () at /usr/lib64/libamdocl64.so #34 0x00007fffe831dd53 in () at /usr/lib64/libamdocl64.so #35 0x00007ffff795ffbe in start_thread () at /lib64/libpthread.so.0 #36 0x00007ffff7a756af in clone () at /lib64/libc.so.6 (gdb)
This might have something to do with the fact your GPU is not fully supported by ROCm-4.0+ - according to the compatibility list from https://github.com/RadeonOpenCompute/ROCm#supported-gpus , support for GFX8 GPUs is "enabled in the ROCm software, though full support is not guaranteed". In either case, this really doesn't look like a Darktable problem.
OK, on top of the above I finally had a chance to try this out myself on three different systems (one with a Polaris 10 GPU, the others with two different Polaris 12 cards) and in either case I have yet to see ROCm 4.1 causing any issues with either Darktable, LuxMark stress tests, or any other OpenCL tasks I have tried.
(In reply to Marek Szuba from comment #8) > OK, on top of the above I finally had a chance to try this out myself on > three different systems (one with a Polaris 10 GPU, the others with two > different Polaris 12 cards) and in either case I have yet to see ROCm 4.1 > causing any issues with either Darktable, LuxMark stress tests, or any other > OpenCL tasks I have tried. Thanks very much for your tests. Now, I'm completely clueless. My card has a Polaris 11 GPU (AMD Radeon RX 570), and one of your checks were done on a Polaris 10 GPU (lesser than mine). However, you report no issues whatsoever. Also, on my part, ROCm 4.0 shows no issues, but ROCm 4.1 prevents darktable from launching. I agree the problem does not lie (most probably) on darktable. Taking a look at my debugging info in a message above, I can see there are some libs belonging to sys-devel/clang and sys-libs/glibc. Since I run a mostly stable system, apart from a few ~packages like darktable and ROCm, could it be the stable sys-devel/clang-11.1.0 or sys-libs/glibc-2.32-r7 cause issues with ROCm 4.1? Which versions do you have installed for these packages?
Alas, I don't think so - my set-up on all Radeon-equipped Gentoo machines is similar to yours, i.e. with only packages without stable keywords (as well as version bumps of stable packages if required by the former) using the ~amd64 keyword. That said, it strikes me as a bit odd that your backtrace shows libraries from both sys-devel/clang and sys-devel/llvm-roc - especially given the stable version of the former has a different major version than the latter. Could you try a) rebuilding LLVM, Clang and the whole ROCm stack, and if it doesn't help b) installing clang-12?
(In reply to Marek Szuba from comment #10) > Alas, I don't think so - my set-up on all Radeon-equipped Gentoo machines is > similar to yours, i.e. with only packages without stable keywords (as well > as version bumps of stable packages if required by the former) using the > ~amd64 keyword. > > That said, it strikes me as a bit odd that your backtrace shows libraries > from both sys-devel/clang and sys-devel/llvm-roc - especially given the > stable version of the former has a different major version than the latter. > Could you try a) rebuilding LLVM, Clang and the whole ROCm stack, and if it > doesn't help b) installing clang-12? I was already in the process of installing clang-12, which triggered some other package updates to their v12, too. I'll post the results when done.
(In reply to Marek Szuba from comment #10) > Alas, I don't think so - my set-up on all Radeon-equipped Gentoo machines is > similar to yours, i.e. with only packages without stable keywords (as well > as version bumps of stable packages if required by the former) using the > ~amd64 keyword. > > That said, it strikes me as a bit odd that your backtrace shows libraries > from both sys-devel/clang and sys-devel/llvm-roc - especially given the > stable version of the former has a different major version than the latter. > Could you try a) rebuilding LLVM, Clang and the whole ROCm stack, and if it > doesn't help b) installing clang-12? Well, I updated to clang-12 but it installed in a new slot and it was impossible for me to get rid of clang-11 (indirectly needed by polkit, in the end). After manually removing v11 of clang and llvm, it was also impossible for me to get mesa (even the latest ~) emerging without asking for clang-11. Nevetherless, I re-emerged darktable but it also failed to launch (segfault). So, I ended up rebuilding LLVM, Clang and the whole ROCm stack,as you suggested, also to no avail. Howvwe, when re-emerging darktable after the whole ROCm stack, I noticed these messages during the config step: ----- -- Found desktop-file-validate CMake Warning at CMakeLists.txt:303 (find_package): Could not find a configuration file for package "LLVM" that is compatible with requested version "11". The following configuration files were considered but not accepted: /usr/lib/llvm/11/lib64/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 /usr/lib/llvm/11/lib/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 Call Stack (most recent call first): CMakeLists.txt:311 (find_llvm) CMake Warning at CMakeLists.txt:303 (find_package): Could not find a configuration file for package "LLVM" that is compatible with requested version "10". The following configuration files were considered but not accepted: /usr/lib/llvm/11/lib64/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 /usr/lib/llvm/11/lib/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 Call Stack (most recent call first): CMakeLists.txt:311 (find_llvm) CMake Warning at CMakeLists.txt:303 (find_package): Could not find a configuration file for package "LLVM" that is compatible with requested version "9". The following configuration files were considered but not accepted: /usr/lib/llvm/11/lib64/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 /usr/lib/llvm/11/lib/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 Call Stack (most recent call first): CMakeLists.txt:311 (find_llvm) CMake Warning at CMakeLists.txt:303 (find_package): Could not find a configuration file for package "LLVM" that is compatible with requested version "8". The following configuration files were considered but not accepted: /usr/lib/llvm/11/lib64/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 /usr/lib/llvm/11/lib/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 Call Stack (most recent call first): CMakeLists.txt:311 (find_llvm) CMake Warning at CMakeLists.txt:303 (find_package): Could not find a configuration file for package "LLVM" that is compatible with requested version "7". The following configuration files were considered but not accepted: /usr/lib/llvm/11/lib64/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 /usr/lib/llvm/11/lib/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 Call Stack (most recent call first): CMakeLists.txt:311 (find_llvm) CMake Warning at CMakeLists.txt:303 (find_package): Could not find a configuration file for package "LLVM" that is compatible with requested version "6.0". The following configuration files were considered but not accepted: /usr/lib/llvm/11/lib64/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 /usr/lib/llvm/11/lib/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 Call Stack (most recent call first): CMakeLists.txt:311 (find_llvm) CMake Warning at CMakeLists.txt:303 (find_package): Could not find a configuration file for package "LLVM" that is compatible with requested version "5.0". The following configuration files were considered but not accepted: /usr/lib/llvm/11/lib64/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 /usr/lib/llvm/11/lib/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 Call Stack (most recent call first): CMakeLists.txt:311 (find_llvm) CMake Warning at CMakeLists.txt:303 (find_package): Could not find a configuration file for package "LLVM" that is compatible with requested version "4.0". The following configuration files were considered but not accepted: /usr/lib/llvm/11/lib64/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 /usr/lib/llvm/11/lib/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 Call Stack (most recent call first): CMakeLists.txt:311 (find_llvm) CMake Warning at CMakeLists.txt:303 (find_package): Could not find a configuration file for package "LLVM" that is compatible with requested version "3.9". The following configuration files were considered but not accepted: /usr/lib/llvm/11/lib64/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 /usr/lib/llvm/11/lib/cmake/llvm/LLVMConfig.cmake, version: 11.1.0 Call Stack (most recent call first): CMakeLists.txt:311 (find_llvm) CMake Warning at CMakeLists.txt:341 (message): Could not find LLVM 3.9+ CMake Warning at CMakeLists.txt:342 (message): Test-compilation of OpenCL programs can not be done. -- Test-compilation of OpenCL programs is disabled. ------ I aslo re-emerged cmake-3.18.5 and rocm-cmake-4.1.0, again to no avail.
I just changed to v4.0 ROCm. darktable luanches fine, but I've seen this: ------ $ darktable LoadLib(libhsa-amd-aqlprofile64.so) failed: libhsa-amd-aqlprofile64.so: cannot open shared object file: No such file or directory (darktable:507897): Gtk-WARNING **: 15:05:38.220: Theme directory panel/22 of theme Mojave-CT-Night has no size field (darktable:507897): Gtk-WARNING **: 15:05:41.614: Theme directory panel/22 of theme Mojave-CT-Night has no size field ----- What is that "libhsa-amd-aqlprofile64.so... No such file or directory" thing? Is it normal? Could it give a clue?
More info: I'm taking a closer look at the config phase when emerging v4.1 ROCm, and I've seen this: ------ >>> Emerging (3 of 9) sys-devel/llvm-roc-4.1.1::gentoo * llvm-rocm-ocl-4.1.1.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking llvm-rocm-ocl-4.1.1.tar.gz to /var/tmp/portage/sys-devel/llvm-roc-4.1.1/work >>> Source unpacked in /var/tmp/portage/sys-devel/llvm-roc-4.1.1/work >>> Preparing source in /var/tmp/portage/sys-devel/llvm-roc-4.1.1/work/llvm-project-rocm-4.1.1/llvm ... . . . -- Looking for sys/resource.h -- Looking for sys/resource.h - found -- Clang version: 12.0.0 -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - Failed -- Looking for include file sys/inotify.h -- Looking for include file sys/inotify.h - found -- LLD version: 12.0.0 -- Registering Bye as a pass plugin (static build: OFF) -- LLVM FileCheck Found: /usr/lib/llvm/11/bin/FileCheck -- Version: 0.0.0 . . . ----- Notice v12 for clang even though I only have v11 installed: ----- $ eix -I clang [I] sys-devel/clang Available versions: (10) 10.0.1^t (11) 11.0.0^t 11.0.1^t 11.1.0(11/11.1)^t (12) ~12.0.0-r1^t **12.0.0.9999*l^t (13) **13.0.0.9999*l^t {debug default-compiler-rt default-libcxx default-lld doc +static-analyzer test xml ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="FreeBSD" LLVM_TARGETS="AArch64 AMDGPU ARC ARM AVR BPF CSKY Hexagon Lanai MSP430 Mips NVPTX PowerPC RISCV Sparc SystemZ VE WebAssembly X86 XCore" PYTHON_SINGLE_TARGET="python3_7 python3_8 python3_9"} Installed versions: 11.1.0(11/11.1)^t(14:31:36 19/04/21)(static-analyzer xml -debug -default-compiler-rt -default-libcxx -default-lld -doc -test ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="32 64 -x32" KERNEL="-FreeBSD" LLVM_TARGETS="AMDGPU BPF NVPTX X86 -AArch64 -ARC -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -PowerPC -RISCV -Sparc -SystemZ -VE -WebAssembly -XCore" PYTHON_SINGLE_TARGET="python3_8 -python3_7 -python3_9") Homepage: https://llvm.org/ Description: C language family frontend for LLVM [I] sys-devel/clang-common Available versions: 10.0.1 11.0.0 11.0.1 11.1.0 ~12.0.0 **12.0.0.9999*l **13.0.0.9999*l Installed versions: 11.1.0(13:59:08 19/04/21) Homepage: https://llvm.org/ Description: Common files shared between multiple slots of clang [I] sys-devel/clang-runtime Available versions: (10.0.1) 10.0.1 (11.0.0) 11.0.0 (11.0.1) 11.0.1 (11.1.0) 11.1.0 (12.0.0) ~12.0.0 **12.0.0.9999*l (13.0.0) **13.0.0.9999*l {+compiler-rt libcxx openmp +sanitize ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32"} Installed versions: 11.1.0(11.1.0)(14:32:37 19/04/21)(compiler-rt openmp sanitize -libcxx ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32") Homepage: https://clang.llvm.org/ Description: Meta-ebuild for clang runtime libraries Found 3 matches ----- Why does llvm-roc-4.1.1 detect clang-12 when only v11 is emerged?
I think I solved the mistery: when I tried to emerge amdgpu-pro-opencl, to give it a chance, it told me mesa had been emerged with USE="opencl" (because I had such flag in my make.conf and I didn't recall it). After removing "opencl" from mesa, re-emerging it as well as the whole ROCm stack and darktable (just in case) and rebooting, darktable launches nicely with ROCm-4.1. Whats more, the ----- LoadLib(libhsa-amd-aqlprofile64.so) failed: libhsa-amd-aqlprofile64.so: cannot open shared object file: No such file or directory ----- message when launching darktable has disappeared. Maybe it would be necessary to add a block warning, similar to the one for amdgpu-pro-opencl, stating that mesa should not be emerged with USE="opencl" when emerging ROCm?
So it's Clover's doing again. We've had this popping up time and time again... Maybe we really do need a warning message about it. To media-libs/mesa maintainers: the problem is that although Clover (i.e. the OpenCL runtime in Mesa) supports only a small set of some rather old Radeons, it still tries to attach itself to newer AMD GPUs - and fails, causing segfaults. Ideally Clover would ignore unsupported GPUs and let the ICD loader possibly move on to the next installed runtime, that said given Mesa has been acting like this since at least mid-2017 (I first saw this problem while testing dev-libs/amdgpu-pro-opencl prior to adding to Gentoo) this probably won't happen any time soon and we might want to warn users about this issue.
(In reply to urcindalo from comment #3) > Thanks for your help. I'm gonna downgrade all my roc* packages: > ----- > These are the packages that would be merged, in reverse order: > > Calculating dependencies... done! > [ebuild UD~] dev-util/rocminfo-4.0.0:0/4.0::gentoo [4.1.0:0/4.1::gentoo] > 15 KiB > [ebuild UD~] dev-libs/rocm-opencl-runtime-4.0.0:0/4.0::gentoo > [4.1.0:0/4.1::gentoo] 981 KiB > [ebuild UD~] dev-libs/rocclr-4.0.0:0/4.0::gentoo [4.1.0:0/4.1::gentoo] > 795 KiB > [ebuild UD~] dev-libs/rocm-comgr-4.0.0:0/4.0::gentoo > [4.1.0:0/4.1::gentoo] 97 KiB > [ebuild UD~] dev-libs/rocr-runtime-4.0.0:0/4.0::gentoo > [4.1.0:0/4.1::gentoo] USE="(-debug%)" 676 KiB > [ebuild UD~] dev-libs/rocm-device-libs-4.0.0:0/4.0::gentoo > [4.1.0:0/4.1::gentoo] 226 KiB > [ebuild UD~] sys-devel/llvm-roc-4.0.0::gentoo [4.1.1::gentoo] > USE="-debug -runtime*" 120.700 KiB > [ebuild UD~] dev-libs/roct-thunk-interface-4.0.0:0/4.0::gentoo > [4.1.0:0/4.1::gentoo] 2.631 KiB > [ebuild UD~] dev-util/rocm-cmake-4.0.0::gentoo [4.1.0::gentoo] 16 KiB > > Total: 9 packages (9 downgrades), Size of downloads: 126.133 KiB > ----- > > > However, I see sys-devel/llvm-roc-4.1 has the "runtime" USE flag enabled by > default, whilst this flag is not enabled for the v4.0. Might that be the > reason? > > Anyway, when the emerge process finishes, we'll know if any of the newer > v4.1 roc* packages is the culprit. The runtime is a USE flag for enabling "runtime" component for llvm-roc. llvm-roc is just a forked version of llvm-project, as I understand. For newer GPUs, we should use rocm-opencl-runtime as the open source opencl runtime or amdgpu-pro-opencl as the proprietary one.
> The runtime is a USE flag for enabling "runtime" component for llvm-roc. > > llvm-roc is just a forked version of llvm-project, as I understand. > > For newer GPUs, we should use rocm-opencl-runtime as the open source opencl > runtime or amdgpu-pro-opencl as the proprietary one. Should be enabling 'clang-rt' if USE='runtime'.
Clover is disabled in our ebuilds now and replaced with the new rusticl implementation. Marking as obsolete...
