Created attachment 1866598 [details] valgrind logs When running sssd test suits (dlopen-tests [1]), we hit the attached valgrind error. This is on Fedora 36 and 37. [1] https://github.com/SSSD/sssd/blob/master/src/tests/dlopen-tests.c ==399173== 0 bytes in 2 blocks are definitely lost in loss record 1 of 11 ==399173== at 0x484586F: malloc (vg_replace_malloc.c:381) ==399173== by 0x4005564: UnknownInlinedFun (rtld-malloc.h:56) ==399173== by 0x4005564: _dl_find_object_update (dl-find_object.c:791) ==399173== by 0x400DCF7: dl_open_worker_begin (dl-open.c:735) ==399173== by 0x49C58ED: _dl_catch_exception (dl-error-skeleton.c:208) ==399173== by 0x400D289: dl_open_worker (dl-open.c:782) ==399173== by 0x49C58ED: _dl_catch_exception (dl-error-skeleton.c:208) ==399173== by 0x400D67B: _dl_open (dl-open.c:883) ==399173== by 0x48FA239: dlopen_doit (dlopen.c:56) ==399173== by 0x49C58ED: _dl_catch_exception (dl-error-skeleton.c:208) ==399173== by 0x49C59A2: _dl_catch_error (dl-error-skeleton.c:227) ==399173== by 0x48F9D3E: _dlerror_run (dlerror.c:138) ==399173== by 0x48FA2D7: dlopen_implementation (dlopen.c:71) ==399173== by 0x48FA2D7: dlopen@@GLIBC_2.34 (dlopen.c:81) ==399173== { <insert_a_suppression_name_here> Memcheck:Leak match-leak-kinds: definite fun:malloc fun:UnknownInlinedFun fun:_dl_find_object_update fun:dl_open_worker_begin fun:_dl_catch_exception fun:dl_open_worker fun:_dl_catch_exception fun:_dl_open fun:dlopen_doit fun:_dl_catch_exception fun:_dl_catch_error fun:_dlerror_run fun:dlopen_implementation fun:dlopen@@GLIBC_2.34 }
Huh. I see one obvious leak: diff --git a/elf/dl-find_object.c b/elf/dl-find_object.c index 2b8df2fd67..b9094a0e17 100644 --- a/elf/dl-find_object.c +++ b/elf/dl-find_object.c @@ -798,7 +798,10 @@ _dl_find_object_update (struct link_map *new_map) map_array[i++] = l; } if (count == 0) - return true; + { + free (map_array); + return true; + } _dl_find_object_link_map_sort (map_array, count); bool ok = _dl_find_object_update_1 (map_array, count); However, I'm not quite sure how to reach this code path. Can you put a conditional breakpoint on the if statement for the count == 0 condition, and see what new_map->l_name is at this point? Thanks.
Hi, you can get it in gdb like this: # prepare environment $ podman run --cap-add SYS_ADMIN --cap-add SYS_PTRACE --security-opt seccomp=unconfined --name test --detach quay.io/sssd/ci-client-devel:fedora-36 && podman exec -u ci --workdir /home/ci test git clone https://github.com/SSSD/sssd && podman exec -u ci --workdir /home/ci/sssd test sudo ./contrib/ci/run --deps-only && podman exec -u ci --workdir /home/ci/sssd test /bin/bash -c 'autoreconf -if && ./configure && make && make check' # run test in valgrind $ podman exec -u ci --workdir /home/ci/sssd test valgrind --leak-check=full ./dlopen-tests # get gdb $ podman exec -u ci --workdir /home/ci/sssd test /bin/bash -c 'CK_FORK=no gdb ./dlopen-tests'
The last command needs to be: podman exec -i -t -u ci --workdir /home/ci/sssd test /bin/bash -c 'CK_FORK=no gdb ./dlopen-tests' And it only works in SELinux permissive mode. Nevertheless, I have convinced myself that I know understand what is going on, despite unrelated debugging troubles (bug 2074993). I'll fix this upstream and backport.
FEDORA-2022-35a1f6fbb0 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-35a1f6fbb0
FEDORA-2022-35a1f6fbb0 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-35a1f6fbb0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-35a1f6fbb0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-35a1f6fbb0 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.