Description of problem: Just ran clinfo. Version-Release number of selected component: clinfo-2.2.17.06.14-1.fc26 Additional info: reporter: libreport-2.9.1 backtrace_rating: 4 cmdline: clinfo crash_function: operator delete executable: /usr/bin/clinfo journald_cursor: s=61b870d8c6864ac1a90e6a00b3904e1a;i=ef696;b=1f8cff23d9d3481dab03a4ff8b2feee3;m=691bbf8b71;t=55599fd7d7d1e;x=d9cb6d4709e1b4ff kernel: 4.11.11-300.fc26.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 13013
Created attachment 1306988 [details] File: backtrace
Created attachment 1306989 [details] File: cgroup
Created attachment 1306990 [details] File: core_backtrace
Created attachment 1306991 [details] File: cpuinfo
Created attachment 1306992 [details] File: dso_list
Created attachment 1306993 [details] File: environ
Created attachment 1306994 [details] File: limits
Created attachment 1306995 [details] File: maps
Created attachment 1306996 [details] File: open_fds
Created attachment 1306997 [details] File: proc_pid_status
Created attachment 1306999 [details] File: var_log_messages
seems like bug in LLVM
Yes! Oh, please please help fix this. BOINC has been broken for over a year, now, and, even after kernel, mesa, and LLVM, and hardware upgrades, I still get LLVM errors.
I've found that uninstalling beignet fixed the crash for me. But also when I re-installed beignet, the crash did not happen either.
Hmm, that's very interesting. I removed beinget and clinfo doesn't crash for me either, now. But, how did this help clinfo? I hope we can still leave this open for LLVM, though, since I have other LLVM problems. I would double check BOINC soon.
(In reply to Paul DeStefano from comment #15) > Hmm, that's very interesting. I removed beinget and clinfo doesn't crash > for me either, now. > > But, how did this help clinfo? > My guess is that since beignet statically links llvm/clang and was exporting some clang/llvm symbols that pocl ended up using. This would be another problem that symbol versioning for LLVM might fix. > I hope we can still leave this open for LLVM, though, since I have other > LLVM problems. I would double check BOINC soon. If you have other LLVM problems, you should file new bugs for them.
This is fixed on rawhide by pocl-1.1-1.fc29.x86_64.rpm.
I think this was fixed by enabling symbol versioning on libLLVM.so. This is too big of a change to backport to f26,f27, so this fix will first appear in f28.
pocl-1.1-2.fc28 lldb-6.0.0-3.fc28 clang-6.0.0-5.fc28 llvm-6.0.0-11.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-02c4091319
clang-6.0.0-5.fc28, lldb-6.0.0-3.fc28, llvm-6.0.0-11.fc28, mesa-18.0.0-2.fc28.1, pocl-1.1-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-02c4091319
clang-6.0.0-5.fc28 lldb-6.0.0-3.fc28 llvm-6.0.0-11.fc28 mesa-18.0.0-3.fc28 pocl-1.1-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-02c4091319
clang-6.0.0-5.fc28, lldb-6.0.0-3.fc28, llvm-6.0.0-11.fc28, mesa-18.0.0-3.fc28, pocl-1.1-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-02c4091319
clang-6.0.0-5.fc28, lldb-6.0.0-3.fc28, llvm-6.0.0-11.fc28, mesa-18.0.0-3.fc28, pocl-1.1-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.