This specific valgrind message is not associated with a memory leak, but ultimately identifying inaccessible user-space data (in this case a null pointer). The kernel source for the routine suggests that the pointer should be dereferenced while copying the mask from user space. Not sure why it doesn’t fault…
I did the run with leak-checking enabled, and the entire output of leaks at the end of the run, some “definitely lost” and some “possibly lost”, were associated with __kmp_xxx calls in libomp. I don’t know if some or all of these are because of incomplete thread shutdowns or because these calls are not covered by the extensive set of leak-check-heuristics (which I set to “all”) in valgrind.
You are correct, it appears not to affect usage. I am a bit fanatical about memory leaks, but if these are things that happen only once per execution, I can probably live with it.
I will look into creating an issue, but I am pretty sure this is not a pytorch problem per se.
Thanks,
Eric