Created attachment 207731 [details] Constructor/destructor workaround Hello. This is a long standing bug (at least for me), but I've decided to report only now. When you use an OpenCL program using lang/clover, the programm will crash at exit. I've tracked the problem to a file src/util/u_queue.c in mesa sources. The segmentation fault occurs while executing atexit handlers (one such hander is added in global_init() ). BTW, there is nothing wrong with atexit_handler() function itself: it can be empty and the result will be the same (segmentation fault). I tried to reproduce this behavior in a test program without success, so I have no idea what is causing the bug. Meanwhile, I wrote a little workarond using constructor and destructor functions (supported by both clang and gcc). This works just fine without any errors.
Thank you for the report and patch. You mention "the program will crash at exit", could you detail what programs crashes? Are they programs from ports/packages? Are they custom programs you're unable to provide additional information, or core's/backtraces for? It may well also be worth reporting this issue upstream, as they may have a much better chance of reproduction or isolation, particularly in debug/traces are unable to be provided
> could you detail what programs crashes? Are they programs from ports/packages? I mean ALL programs using clover ocl provider, including devel/clinfo. One important thing, I forgot to mention is that you must have a suitable GPU (AMD Radeon HD or RX series will do) and drm-kmod port installed or old radeonkms module loaded (latter works only for old HD cards). Try to launch clinfo and you will see something like this: Number of platforms 1 Platform Name Clover Platform Vendor Mesa Platform Version OpenCL 1.1 Mesa 18.3.2 Platform Profile FULL_PROFILE Platform Extensions cl_khr_icd Platform Extensions function suffix MESA Platform Name Clover Number of devices 1 Device Name Radeon RX 580 Series (POLARIS10, DRM 3.23.0, 12.0-RELEASE-p10, LLVM 8.0.1) Device Vendor AMD Device Vendor ID 0x1002 Device Version OpenCL 1.1 Mesa 18.3.2 Driver Version 18.3.2 Device OpenCL C Version OpenCL C 1.1 Device Type GPU Device Profile FULL_PROFILE Max compute units 36 Max clock frequency 1411MHz Max work item dimensions 3 Max work item sizes 256x256x256 Max work group size 256 Preferred work group size multiple 64 Preferred / native vector sizes char 16 / 16 short 8 / 8 int 4 / 4 long 2 / 2 half 8 / 8 (cl_khr_fp16) float 4 / 4 double 2 / 2 (cl_khr_fp64) Half-precision Floating-point support (cl_khr_fp16) Denormals No Infinity and NANs Yes Round to nearest Yes Round to zero No Round to infinity No IEEE754-2008 fused multiply-add No Support is emulated in software No Correctly-rounded divide and sqrt operations No Single-precision Floating-point support (core) Denormals No Infinity and NANs Yes Round to nearest Yes Round to zero No Round to infinity No IEEE754-2008 fused multiply-add No Support is emulated in software No Correctly-rounded divide and sqrt operations No Double-precision Floating-point support (cl_khr_fp64) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Correctly-rounded divide and sqrt operations No Address bits 64, Little-Endian Global memory size 4294967296 (4GiB) Error Correction support No Max memory allocation 3435973836 (3.2GiB) Unified memory for Host and Device No Minimum alignment for any data type 128 bytes Alignment of base address 32768 bits (4096 bytes) Global Memory cache type None Image support No Local memory type Local Local memory size 32768 (32KiB) Max constant buffer size 2147483647 (2GiB) Max number of constant args 16 Max size of kernel argument 1024 Queue properties Out-of-order execution No Profiling Yes Profiling timer resolution 0ns Execution capabilities Run OpenCL kernels Yes Run native kernels No Device Available Yes Compiler Available Yes Device Extensions cl_khr_byte_addressable_store cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp64 cl_khr_fp16 NULL platform behavior clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) Clover clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) Success [MESA] clCreateContext(NULL, ...) [default] Success [MESA] clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) Success (1) Platform Name Clover Device Name Radeon RX 580 Series (POLARIS10, DRM 3.23.0, 12.0-RELEASE-p10, LLVM 8.0.1) clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) Success (1) Platform Name Clover Device Name Radeon RX 580 Series (POLARIS10, DRM 3.23.0, 12.0-RELEASE-p10, LLVM 8.0.1) ICD loader properties ICD loader Name OpenCL ICD Loader ICD loader Vendor OCL Icd free software ICD loader Version 2.2.12 ICD loader Profile OpenCL 2.2 NOTE: your OpenCL library declares to support OpenCL 2.2, but it seems to support up to OpenCL 2.1 only. Ошибка сегментации(core dumped) I think maybe others FreeBSD+OpenCL+clover users may confirm this. My guess is that this is FreeBSD specific, because otherwise it would be noticed (maybe I am incorrect, but I think that there are not many OpenCL users who use FreeBSD).
If you can obtain a backtrace of the crash (as an attachment), that might be handy
This is a backtrace (it's short, no need in attachment). (lldb) bt * thread #1, name = 'clinfo', stop reason = signal SIGSEGV * frame #0: 0x0000000806ce81d0 frame #1: 0x0000000800a030c5 libc.so.7`__cxa_finalize(dso=0x0000000000000000) at atexit.c:239 frame #2: 0x0000000800992cc1 libc.so.7`exit(status=0) at exit.c:74 frame #3: 0x0000000000401526 clinfo`___lldb_unnamed_symbol1$$clinfo + 390
Nothing useful to add here (sorry) other than, reproducible with FreeBSD 14.0-CURRENT. Background to my test: <https://forums.freebsd.org/threads/78825/> ---- % uname -KrU 14.0-CURRENT 1400021 1400021 % sudo pkg install -q -y clover grahamperrin's password: ===== Message from clover-20.2.3: -- ===> NOTICE: This port is deprecated; you may wish to reconsider installing it: Uses EOL Python 2.7 via devel/libclc. It is scheduled to be removed on or after 2021-06-23. % clinfo > /dev/null Segmentation fault (core dumped) % gdb attach clinfo.core GNU gdb (GDB) 10.2 [GDB v10.2 for FreeBSD] Copyright (C) 2021 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.0". 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"... attach: No such file or directory. [New LWP 107531] [New LWP 130945] [New LWP 130946] [New LWP 130947] [New LWP 130948] Core was generated by `clinfo'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000008107d5f00 in ?? () [Current thread is 1 (LWP 107531)] (gdb) bt #0 0x00000008107d5f00 in ?? () #1 0x00000008003e0524 in ?? () #2 0x00007fffffffe388 in ?? () #3 0x0000000800b35a00 in ?? () #4 0x0000000000000000 in ?? () (gdb) q % sudo pkg delete -q -y clover libclc && sudo pkg clean -q -y %
With FreeBSD 12.4, mesa-dri-22.3.3_2, clover-22.3.3_1 and clinfo-3.0.21.02.21 the problem still exists. However, the above (slightly customized) patch does not help me with the mentioned versions.
The patch works after all. I had not noticed that clover is a slave port of mesa-dri and thus did not rebuild it after patching.
attachment 207731 [details] doesn't help here on an Intel iGPU (see ports d8990eff958b). Rusticl isn't affected despite using the same compute support in Gallium. $ pkg install mesa-devel clinfo $ IRIS_ENABLE_CLOVER=1 clinfo >/dev/null 2>&1 Segmentation fault (lldb) bt * thread #1, name = 'clinfo', stop reason = signal SIGSEGV: invalid address (fault address: 0x840e27a10) * frame #0: 0x0000000840e27a10 frame #1: 0x000000082348e55e libc.so.7`__cxa_finalize + 366 frame #2: 0x000000082348eae1 libc.so.7`exit + 33 frame #3: 0x00000000002098b7 clinfo`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:2
While trying to use OpenCL with an RX5700XT on 14-CURRENT, this problem occurred. Sure enough, the patch allows clinfo to run to completion. The patch is a little different in mesa-22.3.7, and I've attached the modified patch (for /usr/ports/graphics/mesa-dri/files; be sure to rebuild all the associated port components).
Created attachment 241985 [details] Constructor/destructor workaround (mesa-22.3.7+) Updated patch for more recent versions of mesa.
I'm pretty sure that I saw this issue when trying to run piglit a while ago. That being said I'm not confident of patching our tree without having upstream in the loop first. Can you open a MR upstream please ?