[Tarantool-patches] [PATCH luajit 1/3] ci: add track-fds Valgrind scenario

Fri Jun 6 17:54:39 MSK 2025

Hi, Sergey,

On 6/6/25 17:03, Sergey Kaplun wrote:
> Hi, Sergey!
> Thanks for the review!
> Please consider my answers below.
>
> On 06.06.25, Sergey Bronnikov wrote:
>> Hello, Sergey,
>>
>> Thanks for the patch! See my comments below.
>>
>> On 6/5/25 08:44, Sergey Kaplun wrote:
>>> This patch adds a new field, track-fds [1], in the Valgrind workflow
>>> matrix to detect descriptor leakage in the tests.
>>>
>>> [1]:https://valgrind.org/docs/manual/manual-core.html#opt.track-fds
>>>
>>> Needed for tarantool/tarantool#11278
>>> ---
>>>    .github/workflows/valgrind-testing.yaml | 9 ++++++++-
>>>    1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/.github/workflows/valgrind-testing.yaml b/.github/workflows/valgrind-testing.yaml
>>> index e6606478..b3c7bc80 100644
>>> --- a/.github/workflows/valgrind-testing.yaml
>>> +++ b/.github/workflows/valgrind-testing.yaml
>>> @@ -38,7 +38,11 @@ jobs:
>>>            # Therefore, testing on this platform is currently
>>>            # disabled.
>>>            BUILDTYPE: [Debug, Release]
>>> -        VALGRIND_SCENARIO: [full, malloc-free-fill-0x00, malloc-free-fill-0xff]
>>> +        VALGRIND_SCENARIO:
>>> +          - full
>>> +          - malloc-free-fill-0x00
>>> +          - malloc-free-fill-0xff
>>> +          - track-fds
>> Why we cannot add "track-fds" to the existed scenario?
> I've thought to add this flag to the "full" scenario. But then I
> realized that we already have "full" workflow running too long, and the
> parallel shorter task will not slow the CI, I suppose.
Ok.
>>>            include:
>>>              - BUILDTYPE: Debug
>>>                CMAKEFLAGS: -DCMAKE_BUILD_TYPE=Debug -DLUA_USE_ASSERT=ON -DLUA_USE_APICHECK=ON
>>> @@ -59,6 +63,9 @@ jobs:
>>>              - VALGRIND_SCENARIO: malloc-free-fill-0xff
>>>                VALGRIND_OPTS: --leak-check=no --malloc-fill=0xff --free-fill=0xff
>>>                JOB_POSTFIX: "malloc/free-fill: 0xff"
>>> +          - VALGRIND_SCENARIO: track-fds
>> According to documentation, the option "print out a list of open file
>> descriptors on exit or on request".
>>
>> So the fd leak detection is semi-automated. How it should work on CI?
> The fd not checked on exit without this flag. I suppose the wording in
> the Valgrind's documentation isn't perfect.
>
> You may test it locally with and without the corresponding flag in
> the`VALGRIND_OPTS` env variable.

FD leak is detected but test is passed:

UpdateCTestConfiguration  from 
:/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64/DartConfiguration.tcl
UpdateCTestConfiguration  from 
:/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64/DartConfiguration.tcl
Test project 
/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 154
     Start 154: test/tarantool-tests/lj-1249-loadfile-fd-leak.test.lua

154: Test command: /bin/valgrind "--leak-check=no" "--track-fds=yes" 
"--error-exitcode=1" 
"--suppressions=/home/sergeyb/sources/MRG/tarantool/third_party/luajit/src/lj.supp" 
"--suppressions=/home/sergeyb/sources/MRG/tarantool/third_party/luajit/src/lj_extra.supp" 
"/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64/src/luajit" 
"-e" 
"dofile[[/home/sergeyb/sources/MRG/tarantool/third_party/luajit/test/luajit-test-init.lua]]" 
"/home/sergeyb/sources/MRG/tarantool/third_party/luajit/test/tarantool-tests/lj-1249-loadfile-fd-leak.test.lua"
154: Working Directory: 
/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64/test/tarantool-tests
154: Environment variables:
154: 
LUA_PATH=/home/sergeyb/sources/MRG/tarantool/third_party/luajit/test/tarantool-tests/?.lua;/home/sergeyb/sources/MRG/tarantool/third_party/luajit/test/tarantool-tests/?/init.lua;/home/sergeyb/sources/MRG/tarantool/third_party/luajit/src/?.lua;/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64/src/?.lua;;
154:  LUAJIT_TEST_USE_VALGRIND=1
154: 
LUA_CPATH=/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64/test/tarantool-tests/utils/?.so;
154: 
LD_LIBRARY_PATH=/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64/test/tarantool-tests/utils:
154: Test timeout computed to be: 10000000
154: ==2176604== Memcheck, a memory error detector
154: ==2176604== Copyright (C) 2002-2022, and GNU GPL'd, by Julian 
Seward et al.
154: ==2176604== Using Valgrind-3.22.0 and LibVEX; rerun with -h for 
copyright info
154: ==2176604== Command: 
/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64/src/luajit 
-e 
dofile[[/home/sergeyb/sources/MRG/tarantool/third_party/luajit/test/luajit-test-init.lua]] 
/home/sergeyb/sources/MRG/tarantool/third_party/luajit/test/tarantool-tests/lj-1249-loadfile-fd-leak.test.lua
154: ==2176604==
154: TAP version 13
154: 1..4
154: ok - correct status, OOM on filename creation
154: ok - correct error message, OOM on filename creation
154: ok - correct status, OOM on error message creation
154: ok - correct error message, OOM on error message creation
154: ==2176604==
154: ==2176604== FILE DESCRIPTORS: 5 open (3 std) at exit.
154: ==2176604== Open file descriptor 4: /dev
154: ==2176604==    at 0x4ABB175: open (open64.c:41)
154: ==2176604==    by 0x4A31B0E: _IO_file_open (fileops.c:188)
154: ==2176604==    by 0x4A31E51: _IO_file_fopen@@GLIBC_2.2.5 
(fileops.c:281)
154: ==2176604==    by 0x4A25EE1: __fopen_internal (iofopen.c:75)
154: ==2176604==    by 0x4A25EE1: fopen@@GLIBC_2.2.5 (iofopen.c:86)
154: ==2176604==    by 0x1FAB1E: luaL_loadfilex (src/lj_load.c:92)
154: ==2176604==    by 0x217F18: lj_cf_loadfile (src/lib_base.c:384)
154: ==2176604==    by 0x2A19B9: lj_BC_FUNCC 
(/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64/src/lj_vm.S:899)
154: ==2176604==    by 0x1E7C81: lua_pcall (src/lj_api.c:1173)
154: ==2176604==    by 0x1D738F: docall (src/luajit.c:134)
154: ==2176604==    by 0x1D6E56: handle_script (src/luajit.c:304)
154: ==2176604==    by 0x1D615B: pmain (src/luajit.c:602)
154: ==2176604==    by 0x2A19B9: lj_BC_FUNCC 
(/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64/src/lj_vm.S:899)
154: ==2176604==
154: ==2176604== Open file descriptor 3: 
/home/sergeyb/sources/MRG/tarantool/third_party/luajit/build/gc64/Testing/Temporary/LastTest.log.tmp
154: ==2176604==    <inherited from parent>
154: ==2176604==
154: ==2176604==
154: ==2176604== HEAP SUMMARY:
154: ==2176604==     in use at exit: 472 bytes in 1 blocks
154: ==2176604==   total heap usage: 1,253 allocs, 1,252 frees, 179,771 
bytes allocated
154: ==2176604==
154: ==2176604== For a detailed leak analysis, rerun with: --leak-check=full
154: ==2176604==
154: ==2176604== For lists of detected and suppressed errors, rerun with: -s
154: ==2176604== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 67 
from 18)
1/1 Test #154: test/tarantool-tests/lj-1249-loadfile-fd-leak.test.lua 
... Passed    0.77 sec

The following tests passed:
     test/tarantool-tests/lj-1249-loadfile-fd-leak.test.lua

100% tests passed, 0 tests failed out of 1

Label Time Summary:
tarantool-tests    =   0.77 sec*proc (1 test)

Total Test time (real) =   0.79 sec

>>> +            VALGRIND_OPTS: --leak-check=no --track-fds=yes
>>> +            JOB_POSTFIX: "track-fds"
>>>        runs-on: [self-hosted, regular, Linux, x86_64]
>>>        name: >
>>>          LuaJIT with Valgrind (Linux/x86_64)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.tarantool.org/pipermail/tarantool-patches/attachments/20250606/b14538b5/attachment.htm>