rpm-software-management/librepo

valgrind shows double free error

joequant opened this issue · 5 comments

==3004523==
determining the fastest mirror (180 hosts).. ==3004523== Invalid free() / delete / delete[] / realloc() --:-- ETA
==3004523== at 0x483EF6C: free (vg_replace_malloc.c:755)
==3004523== by 0x8102709: ??? (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x80E447F: ??? (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x80E66A8: curl_multi_remove_handle (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x74BDDE1: ??? (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BE4F1: lr_fastestmirror_detailed (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BEA6B: lr_fastestmirror (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BEC75: lr_fastestmirror_sort_internalmirrorlists (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BEEC1: lr_fastestmirror_sort_internalmirrorlist (in /usr/lib64/librepo.so.0)
==3004523== by 0x74C1ADA: lr_handle_prepare_internal_mirrorlist (in /usr/lib64/librepo.so.0)
==3004523== by 0x74C282F: lr_handle_perform (in /usr/lib64/librepo.so.0)
==3004523== by 0x744F14A: libdnf::Repo::Impl::lrHandlePerform(_LrHandle*, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, bool) (in /usr/lib64/libdnf.so.2)
==3004523== Address 0x52ed260 is 0 bytes inside a block of size 848 free'd
==3004523== at 0x483EF6C: free (vg_replace_malloc.c:755)
==3004523== by 0x8101118: ??? (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x8102439: ??? (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x80E4457: ??? (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x80E66A8: curl_multi_remove_handle (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x74BDDE1: ??? (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BE4F1: lr_fastestmirror_detailed (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BEA6B: lr_fastestmirror (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BEC75: lr_fastestmirror_sort_internalmirrorlists (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BEEC1: lr_fastestmirror_sort_internalmirrorlist (in /usr/lib64/librepo.so.0)
==3004523== by 0x74C1ADA: lr_handle_prepare_internal_mirrorlist (in /usr/lib64/librepo.so.0)
==3004523== by 0x74C282F: lr_handle_perform (in /usr/lib64/librepo.so.0)
==3004523== Block was alloc'd at
==3004523== at 0x4841208: calloc (vg_replace_malloc.c:1117)
==3004523== by 0x80D6A03: ??? (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x80D6DA6: ??? (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x80D7A28: ??? (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x80CE7EF: ??? (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x80E4DAC: ??? (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x80E6085: curl_multi_perform (in /usr/lib64/libcurl.so.4.7.0)
==3004523== by 0x74BDC97: ??? (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BE4F1: lr_fastestmirror_detailed (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BEA6B: lr_fastestmirror (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BEC75: lr_fastestmirror_sort_internalmirrorlists (in /usr/lib64/librepo.so.0)
==3004523== by 0x74BEEC1: lr_fastestmirror_sort_internalmirrorlist (in /usr/lib64/librepo.so.0)
==3004523==

Thanks for the report!
Can you specify what versions are you using? (for example the output of: rpm -q librepo libdnf dnf libcurl)

Also do you have a reproducer for this?

I have tried running: valgrind dnf --repo fedora makecache with fastestmirror enabled for the fedora repo on Fedora 34 but didn't get any errors.

(base) [joe@big-apple bitstation (develop)]$ rpm -q lib64repo0 lib64dnf2 dnf lib64curl4
lib64repo0-1.14.1-1.mga9
lib64dnf2-0.63.1-1.mga9
dnf-4.8.0-1.mga9
lib64curl4-7.77.0-1.mga9

mirrorlist.txt

Here is what causes an error

[mirrors]
name=mirrors
mirrorlist=file:///etc/yum.repos.d/mirrorlist
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Mageia
enabled=1

Still can't reproduce this. Does it happen consistently every time for you?

Also looking at the valgrind output you provided and librepo code I think this is actually a libcurl problem.
It would match with this report: curl/curl#7292 (comment)

(I did find one unrelated memory leak in the librepo code: #250)

I believe this is resolved.