valgrind reports leak in cufftPlanMany - supress?

Accelerated Computing GPU-Accelerated Libraries
1

I am developing an application which uses cufftPlanMany, and valgrind run with --leak-check=full --track-origins=yes is reporting a leak of 1200 bytes each time PlanMany is called;

==32752==    1,200 bytes in 6 blocks are definitely lost in loss record 520 of 612
==32752==    at 0x4C2CAEE: operator new(unsigned long) (vg_replace_malloc.c:333)
==32752==    by 0x6ECDB06: ??? (in /opt/tcbsys/cuda/7.0.28/lib64/libcufft.so.7.0.28)
==32752==    by 0x6ECEE56: ??? (in /opt/tcbsys/cuda/7.0.28/lib64/libcufft.so.7.0.28)
==32752==    by 0x6ECD199: ??? (in /opt/tcbsys/cuda/7.0.28/lib64/libcufft.so.7.0.28)
==32752==    by 0x6ECC692: ??? (in /opt/tcbsys/cuda/7.0.28/lib64/libcufft.so.7.0.28)
==32752==    by 0x6ECB12E: ??? (in /opt/tcbsys/cuda/7.0.28/lib64/libcufft.so.7.0.28)
==32752==    by 0x6E7DEC6: ??? (in /opt/tcbsys/cuda/7.0.28/lib64/libcufft.so.7.0.28)
==32752==    by 0x6E7E086: cufftLockPlan (in /opt/tcbsys/cuda/7.0.28/lib64/libcufft.so.7.0.28)
==32752==    by 0x6ED2AA2: cufftMakePlanMany (in /opt/tcbsys/cuda/7.0.28/lib64/libcufft.so.7.0.28)
==32752==    by 0x6ED3FA1: cufftPlanMany (in /opt/tcbsys/cuda/7.0.28/lib64/libcufft.so.7.0.28)

I have understood that valgrind may report false leaks in cuda libraries and that I may need to use an appropriate suppression file. Is there such a file readily available, or is this leak “true”? Of course I could make one, but the question is really if these are actual leaks. At no point am I calling new, so I unless I have gravely misunderstood valgrind, this leak occurs inside libcufft, no?

cuda-memcheck does not return any errors or leaks. I am using cuda 7.5 on a GTX980Ti.

Thaks for any suggestions, thoughts or help.

2

you’re using CUDA 7.0 according to valgrind:

libcufft.so.7.0.28
            ^^^

try switching to cuda 7.5

3

You are entirely correct. Although, interestingly, the size of the “leak” is now smaller, but persists:

==28300== 1,152 bytes in 4 blocks are definitely lost in loss record 136 of 153
==28300==    at 0x4C2C86A: operator new(unsigned long, std::nothrow_t const&) (vg_replace_malloc.c:376)
==28300==    by 0x6BDC52B: ??? (in /opt/tcbsys/cuda/7.5.18/lib64/libcufft.so.7.5.18)
==28300==    by 0x6AD4F3D: ??? (in /opt/tcbsys/cuda/7.5.18/lib64/libcufft.so.7.5.18)
==28300==    by 0x6AD9E24: ??? (in /opt/tcbsys/cuda/7.5.18/lib64/libcufft.so.7.5.18)
==28300==    by 0x6AD6C00: ??? (in /opt/tcbsys/cuda/7.5.18/lib64/libcufft.so.7.5.18)
==28300==    by 0x6AC38E1: ??? (in /opt/tcbsys/cuda/7.5.18/lib64/libcufft.so.7.5.18)
==28300==    by 0x6AC0C59: ??? (in /opt/tcbsys/cuda/7.5.18/lib64/libcufft.so.7.5.18)
==28300==    by 0x6ABEA9E: ??? (in /opt/tcbsys/cuda/7.5.18/lib64/libcufft.so.7.5.18)
==28300==    by 0x6ABC756: ??? (in /opt/tcbsys/cuda/7.5.18/lib64/libcufft.so.7.5.18)
==28300==    by 0x6ABC926: cufftLockPlan (in /opt/tcbsys/cuda/7.5.18/lib64/libcufft.so.7.5.18)
==28300==    by 0x6AC6C4F: cufftMakePlanMany (in /opt/tcbsys/cuda/7.5.18/lib64/libcufft.so.7.5.18)
==28300==    by 0x6AC7FB1: cufftPlanMany (in /opt/tcbsys/cuda/7.5.18/lib64/libcufft.so.7.5.18)
4

You may want to just file a bug. If you want to pursue it here, I suggest providing the shortest complete code that demonstrates the above error, along with platform information and the valgrind command you used to demonstrate.