After the changes introduced in #7451, it was discovered that a memory leak had been either produced, or revealed in the linux environment.
With this cmake configuration:
# cmake in linux env from cwd right above ./DXC repo:
cmake ./DXC -B ./hlsl.bin -C ./DXC/cmake/caches/PredefinedParams.cmake -DCMAKE_BUILD_TYPE=Debug -G Ninja -DSPIRV_BUILD_TESTS=ON -DCMAKE_C_COMPILER=clang-18 -DCMAKE_CXX_COMPILER=clang++-18 -DLLVM_ENABLE_WERROR=On -DLLVM_USE_SANITIZER='Address;Undefined' -DLLVM_ENABLE_LIBCXX=On -DLLVM_USE_LINKER=lld
when running ./hlsl.bin/bin/dxc --version, the Leak Sanitizer detects this leak
=================================================================
==32533==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x5614aa77d6bd in operator new(unsigned long) (/home/jbatista/repos/hlsl.bin/bin/dxc-3.7+0x4fe6bd) (BuildId: fd646a5ae4e18783)
#1 0x7f744fbaad12 (<unknown module>)
#2 0x7f744fbaa465 (<unknown module>)
#3 0x7f744fba8a7b (<unknown module>)
#4 0x7f745a2b147d in call_init elf/dl-init.c:70:3
SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s).
Separately, one can use valgrind to detect this leak, by configuring cmake without the DLLVM_USE_SANITIZER argument above, and when building DXC, instead of ninja, using CCC_OVERRIDE_OPTIONS=s/-g/-gdwarf-4/ ninja so that valgrind can correctly interpret the debug symbols.
It is known that in a clean environment, using lldb with lldb -- ./hlsl.bin/bin/dxc --version, then immediately running image list from within lldb, no libraries are loaded, the only associated image is dxc. But after running dxc --version with r, and rerunning image list, libdxcompiler.so appears to still be loaded:
Separately, if one changes \tools\clang\tools\dxc\CMakeLists.txt:27 to simply target_link_libraries(dxc dxclib), then the leak increases to 32 bytes.
This issue will be resolved when there is confidence that there is no memory leak, and an appropriate design for loading and unloading dynamic libraries is implemented. The proper solution to the leak may be to make some edits to the CMakeLists.txt file mentioned above.
After the changes introduced in #7451, it was discovered that a memory leak had been either produced, or revealed in the linux environment.
With this cmake configuration:
when running
./hlsl.bin/bin/dxc --version, the Leak Sanitizer detects this leakSeparately, one can use valgrind to detect this leak, by configuring cmake without the DLLVM_USE_SANITIZER argument above, and when building DXC, instead of
ninja, usingCCC_OVERRIDE_OPTIONS=s/-g/-gdwarf-4/ ninjaso that valgrind can correctly interpret the debug symbols.It is known that in a clean environment, using lldb with
lldb -- ./hlsl.bin/bin/dxc --version, then immediately runningimage listfrom within lldb, no libraries are loaded, the only associated image is dxc. But after running dxc --version withr, and rerunningimage list, libdxcompiler.so appears to still be loaded:Separately, if one changes \tools\clang\tools\dxc\CMakeLists.txt:27 to simply
target_link_libraries(dxc dxclib), then the leak increases to 32 bytes.This issue will be resolved when there is confidence that there is no memory leak, and an appropriate design for loading and unloading dynamic libraries is implemented. The proper solution to the leak may be to make some edits to the CMakeLists.txt file mentioned above.