-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GDAL 3.5.1 crashes with Signal 4 Illegal Instruction #6150
Comments
Did you build GDAL yourself or used a pre-built GDAL ? The crash seems to occur in libarrow.so used by the OGR Parquet driver. If you built yourself and don't need Parquet support, then disable it. |
I use pre-build GDAL from manjaro repositories. And yes, uninstalling arrow package almost fixed gdal behavior, (with an exception of warnings messages "ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directory". |
probably first to the person in charge of the manjaro repository / the one who built libarrow |
Might also be related to snappy (dependency of arrow) - both arrow and snappy uses instructions that are not available everywhere. I think arrow does check whether the instruction is available at runtime, but snappy doesn't. |
The problem is the arrow package. apache/arrow#12681 The solution: is to rebuild the arrow package manually with flags -DARROW_SIMD_LEVEL=SSE4_2 or -DARROW_SIMD_LEVEL=NONE, depending on the instructions set supported by your CPU |
Also ran into this, on Arch Linux (very similar to Manjaro). I filed a bug report for the packagers of the Edit: And another report for the packagers of the Edit 2: Arch maintainers consider this an upstream issue, so filed #6281 for the error spam. |
This "Illegal instruction (core dumped)" also affects the official docker image |
Does it happen when opening any dataset or just a Feather/Parquet one? |
According to https://arrow.apache.org/docs/cpp/env_vars.html#envvar-ARROW_USER_SIMD_LEVEL , default builds should only required SSE4.2 which should be available, unless you run a very old hardware. Can you check if the following returns a non-empty string: |
CPU flags: OK:
Fail:
|
Another system: Fail:
But weirdly OK...
|
OK, so sse4.2 present, but no avx2 . Are you sure the issue is with libarrow ? Because we've also identified an issue with libtiledb which required avx2. Can you try to "docker pull ghcr.io/osgeo/gdal:ubuntu-full-latest" again? I've just refreshed it a few minutes ago with a tiledb build that no longer requires avx2. See discussion at https://lists.osgeo.org/pipermail/gdal-dev/2024-February/058392.html |
BINGO! Fixed! You are awesome!
Yes, likely: c4505ed |
After last update, GDAL upgraded to ver. 3.5.1. and started to crash.
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:
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.
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:
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(tm)-8350 Eight-Core Processor
Семейство ЦПУ: 21
Модель: 2
Thread(s) per core: 2
Ядер на сокет: 4
Сокетов: 1
Степпинг: 0
Frequency boost: enabled
CPU(s) scaling MHz: 38%
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:
NUMA node(s): 1
NUMA node0 CPU(s): 0-7
Vulnerabilities:
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
The text was updated successfully, but these errors were encountered: