[ci] increase valgrind bytes lost limit to 352

[jameslamb]

See #5403 (comment) for details.

This PR slightly increases the number of "possibly lost bytes" allowed in the valgrind CI job. Since this is coming from the exact same place as a previous false positive, I think it's highly likely that CRAN will not complain about this.

[jameslamb]

/gha run r-valgrind

Workflow R valgrind tests has been triggered! 🚀
https://github.com/microsoft/LightGBM/actions/runs/2879357468

Status: failure ❌.

[jameslamb]

/gha run r-valgrind

Workflow R valgrind tests has been triggered! 🚀
https://github.com/microsoft/LightGBM/actions/runs/2882626199

Status: failure ❌.

[jameslamb]

Really weird, on this PR (which only changes this test script), I see two valgrind errors. (build link)

==4736== 
==4736== HEAP SUMMARY:
==4736==     in use at exit: 279,424,869 bytes in 49,076 blocks
==4736==   total heap usage: 11,012,270 allocs, 10,963,194 frees, 9,478,540,270 bytes allocated
==4736== 
==4736== 336 bytes in 1 blocks are possibly lost in loss record 151 of 2,896
==4736==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4736==    by 0x40147D9: calloc (rtld-malloc.h:44)
==4736==    by 0x40147D9: allocate_dtv (dl-tls.c:375)
==4736==    by 0x40147D9: _dl_allocate_tls (dl-tls.c:634)
==4736==    by 0x4DF4834: allocate_stack (allocatestack.c:430)
==4736==    by 0x4DF4834: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==4736==    by 0xCF58426: cli__start_thread (thread.c:51)
==4736==    by 0xCF5849A: clic_start_thread (thread.c:74)
==4736==    by 0x4953BC4: R_doDotCall (dotcode.c:607)
==4736==    by 0x49C2C16: bcEval (eval.c:7682)
==4736==    by 0x499DB95: Rf_eval (eval.c:748)
==4736==    by 0x49A0904: R_execClosure (eval.c:1918)
==4736==    by 0x49A05B7: Rf_applyClosure (eval.c:1844)
==4736==    by 0x49B2122: bcEval (eval.c:7094)
==4736==    by 0x499DB95: Rf_eval (eval.c:748)
==4736== 
==4736== 352 bytes in 1 blocks are possibly lost in loss record 153 of 2,896
==4736==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4736==    by 0x40147D9: calloc (rtld-malloc.h:44)
==4736==    by 0x40147D9: allocate_dtv (dl-tls.c:375)
==4736==    by 0x40147D9: _dl_allocate_tls (dl-tls.c:634)
==4736==    by 0x4DF4834: allocate_stack (allocatestack.c:430)
==4736==    by 0x4DF4834: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==4736==    by 0x575B1EF: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==4736==    by 0x5751A10: GOMP_parallel (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==4736==    by 0x16C99F37: OMP_NUM_THREADS() (openmp_wrapper.h:22)
==4736==    by 0x16FE6776: OMP_SET_NUM_THREADS(int) (openmp_wrapper.h:29)
==4736==    by 0x16FDACBE: LGBM_DatasetCreateFromCSC (c_api.cpp:1462)
==4736==    by 0x1700C14E: LGBM_DatasetCreateFromCSC_R (lightgbm_R.cpp:183)
==4736==    by 0x4953D8A: R_doDotCall (dotcode.c:627)
==4736==    by 0x495ED3E: do_dotcall (dotcode.c:1284)
==4736==    by 0x499E245: Rf_eval (eval.c:851)
==4736== 
==4736== LEAK SUMMARY:
==4736==    definitely lost: 0 bytes in 0 blocks
==4736==    indirectly lost: 0 bytes in 0 blocks
==4736==      possibly lost: 688 bytes in 2 blocks
==4736==    still reachable: 279,424,181 bytes in 49,074 blocks
==4736==                       of which reachable via heuristic:
==4736==                         newarray           : 4,264 bytes in 1 blocks
==4736==         suppressed: 0 bytes in 0 blocks
==4736== Reachable blocks (those to which a pointer was found) are not shown.
==4736== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==4736== 
==4736== For lists of detected and suppressed errors, rerun with: -s
==4736== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

But on #5403, I only see one error. (build link)

==4762== 
==4762== HEAP SUMMARY:
==4762==     in use at exit: 279,420,158 bytes in 49,072 blocks
==4762==   total heap usage: 10,987,600 allocs, 10,938,528 frees, 9,460,895,963 bytes allocated
==4762== 
==4762== 352 bytes in 1 blocks are possibly lost in loss record 152 of 2,904
==4762==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4762==    by 0x40147D9: calloc (rtld-malloc.h:44)
==4762==    by 0x40147D9: allocate_dtv (dl-tls.c:375)
==4762==    by 0x40147D9: _dl_allocate_tls (dl-tls.c:634)
==4762==    by 0x4DF4834: allocate_stack (allocatestack.c:430)
==4762==    by 0x4DF4834: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==4762==    by 0x575B1EF: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==4762==    by 0x5751A10: GOMP_parallel (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==4762==    by 0x16C99F47: OMP_NUM_THREADS() (openmp_wrapper.h:22)
==4762==    by 0x16FE6E64: OMP_SET_NUM_THREADS(int) (openmp_wrapper.h:29)
==4762==    by 0x16FDB3AC: LGBM_DatasetCreateFromCSC (c_api.cpp:1462)
==4762==    by 0x1700C83C: LGBM_DatasetCreateFromCSC_R (lightgbm_R.cpp:183)
==4762==    by 0x4953D8A: R_doDotCall (dotcode.c:627)
==4762==    by 0x495ED3E: do_dotcall (dotcode.c:1284)
==4762==    by 0x499E245: Rf_eval (eval.c:851)
==4762== 
==4762== LEAK SUMMARY:
==4762==    definitely lost: 0 bytes in 0 blocks
==4762==    indirectly lost: 0 bytes in 0 blocks
==4762==      possibly lost: 352 bytes in 1 blocks
==4762==    still reachable: 279,419,806 bytes in 49,071 blocks
==4762==                       of which reachable via heuristic:
==4762==                         newarray           : 4,264 bytes in 1 blocks
==4762==         suppressed: 0 bytes in 0 blocks
==4762== Reachable blocks (those to which a pointer was found) are not shown.
==4762== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==4762== 
==4762== For lists of detected and suppressed errors, rerun with: -s
==4762== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

🤔

[jameslamb]

/gha run r-valgrind

Workflow R valgrind tests has been triggered! 🚀
https://github.com/microsoft/LightGBM/actions/runs/2886648044

Status: success ✔️.

[shiyu1994]

Why the R valgrind tests succeed by simply rerunning?

[jameslamb]

Why the R valgrind tests succeed by simply rerunning?

it's very strange! I don't understand why.

But I hope that since the other error that showed up in the previous failed build looks unrelated to LightGBM (the one with clic_start_thread in the trace), it's somethimg we can safely ignore.

I think we should merge this PR.

[shiyu1994]

@jameslamb Thanks you!

[github-actions]

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.