GDAL 3.5.1 crashes with Signal 4 Illegal Instruction

After last update, GDAL upgraded to ver. 3.5.1. and started to crash. GDAL is a major dependency for almost all geospatial applications.

Some gdal binaries (gdal-config, for an example) still work, but most of them gives an error “Illegal instruction (core dumped)”.

My system:

OS: Manjaro 21.3.6 Ruah
Kernel: x86_64 Linux 5.15.57-2-MANJARO
Uptime: 26m
Packages: 1469
Shell: bash
Resolution: 1920x1080
DE: Xfce4
WM: Xfwm4
WM Theme: Matcha-sea
GTK Theme: Matcha-sea [GTK2]
Icon Theme: Papirus-Maia
Font: Noto Sans 10
Disk: 1,5T / 6,8T (23%)
CPU: AMD FX-8350 Eight-Core @ 8x 4GHz
GPU: AMD RS780 (DRM 2.50.0 / 5.15.57-2-MANJARO, LLVM 14.0.6)
RAM: 1829MiB / 19485MiB

coredumpctl info:
       PID: 2333 (gdalinfo)
       UID: 1000 (rstanislav)
       GID: 1000 (rstanislav)
    Signal: 4 (ILL)
 Timestamp: Tue 2022-08-02 13:33:42 MSK (5min ago)

Command Line: gdalinfo
Executable: /usr/bin/gdalinfo
Control Group: /user.slice/user-1000.slice/session-2.scope
Unit: session-2.scope
Slice: user-1000.slice
Session: 2
Owner UID: 1000 (rstanislav)
Boot ID: 6b3e5ea1666440239afb43c4a246b953
Machine ID: 6313df66156547e292fedaf552861e30
Hostname: rstanislav-ipen
Storage: /var/lib/systemd/coredump/core.gdalinfo.1000.6b3e5ea1666440239afb43c4a246b953.2333.1659436422>
Disk Size: 743.6K
Message: Process 2333 (gdalinfo) of user 1000 dumped core.

            Module with build-id 125b0285aa529b1b1396ff79a856cc580f53371b
            Module with build-id 7f92dc764545b3d8e058f547553713232168c9db
            Module with build-id 86a9fa3c8369df69f01ddb2fb38c14307b91773d
            Module with build-id c3b31b7dd733754897f96dc1b0919b8ea6446c

Some google results assume that such an error may be caused by CPU unsupportance, but I dont know how to confirm that. Anyway, my lscpu:


Архитектура: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Порядок байт: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
ID прроизводителя: AuthenticAMD
Имя модели: AMD FX™-8350 Eight-Core Processor
Семейство ЦПУ: 21
Модель: 2
Thread(s) per core: 2
Ядер на сокет: 4
Сокетов: 1
Степпинг: 0
Frequency boost: enabled
CPU(s) scaling MHz: 37%
CPU max MHz: 4000,0000
CPU min MHz: 1400,0000
BogoMIPS: 8003.18
Флаги: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx f
xsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good no
pl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4
_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse
4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topo
ext perfctr_core perfctr_nb cpb hw_pstate ssbd ibpb vmmcall bmi1 arat npt lbrv svm_lo
ck nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
Virtualization features:
Виртуализация: AMD-V
Caches (sum of all):
L1d: 128 KiB (8 instances)
L1i: 256 KiB (4 instances)
L2: 8 MiB (4 instances)
L3: 8 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-7
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Mitigation; untrained return thunk; SMT vulnerable
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines, IBPB conditional, STIBP disabled, RSB filling
Srbds: Not affected
Tsx async abort: Not affected

Ok, that was the problem Test failure in arrow-compute-aggregate-test · Issue #12681 · apache/arrow · GitHub

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.