Bug 219562 - lang/pocl: crash during initialization
Summary: lang/pocl: crash during initialization
Status: Closed Feedback Timeout
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
Keywords: needs-qa
Depends on: 233495
  Show dependency treegraph
Reported: 2017-05-26 01:39 UTC by Johannes M Dieterich
Modified: 2019-09-07 11:11 UTC (History)
4 users (show)

See Also:
jbeich: maintainer-feedback? (ohartmann)


Note You need to log in before you can comment on or make changes to this bug.
Description Johannes M Dieterich freebsd_committer 2017-05-26 01:39:01 UTC
lang/pocl is broken for me for even just clinfo on two independent platforms:

on Carrizo:

$ clinfo
CommandLine Error: Option 'enable-value-profiling' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

on a Broadwell EP dual socket it gets a bit further:

$ clinfo
Number of platforms                               1
 Platform Name                                   Portable Computing Language
 Platform Vendor                                 The pocl project
 Platform Version                                OpenCL 2.0 pocl 0.14, LLVM 4.0.1
 Platform Profile                                FULL_PROFILE
 Platform Extensions                             cl_khr_icd
 Platform Extensions function suffix             POCL
Segmentation fault (core dumped)

Quick gdb (sorry, no debug symbols) points to libhwloc

(gdb) bt
#0  0x0000000802d26075 in ?? () from /usr/local/lib/libhwloc.so.5
#1  0x0000000802d25f2d in ?? () from /usr/local/lib/libhwloc.so.5
#2  0x0000000802d25a77 in ?? () from /usr/local/lib/libhwloc.so.5
#3  0x0000000802d0c95b in hwloc_topology_load ()
   from /usr/local/lib/libhwloc.so.5
#4  0x0000000801722923 in ?? () from /usr/local/lib/libpocl.so.1.7.0
#5  0x000000080171e8ec in ?? () from /usr/local/lib/libpocl.so.1.7.0
#6  0x00000008017193f3 in ?? () from /usr/local/lib/libpocl.so.1.7.0
#7  0x00000008016f1fc4 in ?? () from /usr/local/lib/libpocl.so.1.7.0
#8  0x0000000800839a4a in clGetDeviceIDs () from /usr/local/lib/libOpenCL.so.1
#9  0x0000000000401fb9 in ?? ()
#10 0x0000000000409867 in ?? ()
#11 0x000000000040151f in ?? ()
#12 0x0000000800633000 in ?? ()
#13 0x0000000000000000 in ?? ()
Comment 1 Bugzilla Automation freebsd_committer 2017-05-26 01:39:01 UTC
Maintainer informed via mail
Comment 2 Jan Beich freebsd_committer 2017-08-27 19:11:04 UTC
What FreeBSD version/architecture? If -CURRENT then update as some dlopen() issues have been fixed a few months ago. Otherwise, build lang/pocl and everything from LIB_DEPENDS with debugging symbols (i.e., pass WITH_DEBUG=1) then show "bt" (or "bt full") output again.
Comment 3 Johannes M Dieterich freebsd_committer 2017-10-20 03:28:11 UTC
Had tested on later HEAD amd64 machines: carrizo, threadripper, broadwell EP architectures. Same issue in all cases (if I recall correctly): segfaults. Currently the package does not build for me, so can't do more testing right now.

Let me ask the other way round: on which architectures have you successfully run the current version (where "run" can be as primitive as "exec clinfo")?
Comment 4 O. Hartmann 2017-10-20 06:57:40 UTC
I have already submitted a proposal for a patch (PR 223032).

I do not have modern and sophisticated architectures at hand. But I realise some serious issues with older OCL software which successfully ran a while ago on CURRENT which is not on recent builds.
Comment 5 O. Hartmann 2017-11-26 09:04:00 UTC

My last statement reflects that I didn't got the problem, sorry for that. We ran into a similar problem with graphics/blender these days were OpenCL is enabled. I stumbled over this report:


On boxes where I have installesd mesa-lib and beignet as well, pocl doesn't work. Blender doesn't work either.

With #223032 I submitted a patch making lang/pocl build again - but I have never tested it against build environments depending on gcc and I guess the issue in PR 0223032 is only fixed for clang builds. So I need help on this, please.
Comment 6 O. Hartmann 2017-11-26 09:11:41 UTC
Just for the record, this one is on the LLVM bug list:

Comment 7 O. Hartmann 2017-12-25 12:35:02 UTC
I just try to update our port from pocl 0.14 to pocl 1.0, since pocl-1.0 is out for a couple of days now.

The problem the initial poster faced is still persistent and I was searching the net for some solutions. I'm not a compiler expert and my resources are limited. I tried compiling lang/pocl with the option by setting


via cmake, but this put a considerable load and compile time to the port build I do not want to bear.

Searching the bug databse at LLVM.ORG, I found some references to this type of bug, but at different places and I'm wondering if this is still with FreeBSD's implementation of CLANG/LLVM.

Don't link ObjCARCOpts twice. Fixes PR22543

and another one, which seems unresolved to me, is this one:

Bug 22952: cl::opt + LLVM_BUILD_LLVM_DYLIB is completely broken

Since I use on most recent CURRENT still the default linker, which is ld.bfd, I have not checked whether this problem is still with the LLVM/CLANG ld.lld linker, since using the new linker causes a lot of trouble with important ports.

It would be great if someone with a more decent insight into this LLVM linker stuff could take a look. Thanks in advance,

Comment 8 Nikolai Lifanov freebsd_committer 2018-02-21 20:21:43 UTC
Can you re-test this with the last patch in this issue please?

The patch updates pocl to 1.0 and llvm to 5.0, and I'm no longer seeing the crash.
Comment 9 Walter Schwarzenfeld freebsd_triage 2018-03-05 19:32:03 UTC
@ O. Hartmann 
Please, change mail address in Makefile.
Comment 10 Walter Schwarzenfeld freebsd_triage 2019-08-11 13:27:12 UTC
pocl version is 1.3, llvm default is llvm90. Is this still relevant?