Re: [pocl-devel] pocl 1.4

[Andreas K. <li...@in...>]

Hi Michal,

"Michal Babej (TAU)" <mic...@tu...> writes:
>> valgrind. Were you able to reproduce that on your end?
>
> Yes; I commented in the issue.

Thanks very much to you and Pekka for taking a look. We'll continue to
pursue this and will share what we find.

>> Possible memory leak in POCL:
>
> https://gitlab.tiker.net/inducer/pytential/issues/131
>
> We have a buildbot which tracks memory leaks by building pocl with
> Address Sanitizer (cmake -DENABLE_ASAN=ON). I have discovered that due
> to some faulty logic in cmake/ctest, some memleaks went unnoticed;
> this has now been fixed in release_1_4 & master. Ofc it's possible
> that it's a different leak; the test coverage is not full.
>
> Unfortunately i don't have any good advice for finding memory leaks
> when using pocl in Python. ASan may be impossible to use, and valgrind
> will probably report a lot of false positives (and be slow). Also i'm
> not sure it's possible to force Python to release an object, which
> makes it even more problematic. With C/C++ it's much simpler - if you
> call clUnloadPlatformCompiler() at the end of your program, and you've
> properly released all cl_* objects, pocl will additionally release all
> LLVM related data, including long-lived static data structures; after
> this there should only be a single memory leak, from LLVM signal
> handlers.

Thanks for following up on the memory leaks. I've done a run on our end
to investigate, and I've found that 1.4 still consumes considerably more
memory than the Intel ICD, but it seems there has been some measure of
improvement from 1.2 to 1.4:

https://gitlab.tiker.net/inducer/pytential/issues/131

Best,
Andreas