Description of problem: createrepo_c $DIR --baseurl=file://$DIR --outputdir=$REPO_DIR --pkglist=$PKG_LIST --update --database --unique-md-filenames --workers=5 Version-Release number of selected component: createrepo_c-0.1.15-1.fc18 Additional info: backtrace_rating: 4 cmdline: createrepo_c /home/dmach/cvs/distill_ng/tests/data/_composes/DP-1.0-20130306.12/work/global/download/ --baseurl=file:///home/dmach/cvs/distill_ng/tests/data/_composes/DP-1.0-20130306.12/work/global/download/ --outputdir=/home/dmach/cvs/distill_ng/tests/data/_composes/DP-1.0-20130306.12/work/global/repo --pkglist=/home/dmach/cvs/distill_ng/tests/data/_composes/DP-1.0-20130306.12/work/global/package_list/global.conf --update --database --unique-md-filenames --workers=5 crash_function: rpmKeyringFree environ: executable: /usr/bin/createrepo_c kernel: 3.8.1-201.fc18.x86_64 uid: 500 Truncated backtrace: Thread no. 1 (5 frames) #4 rpmKeyringFree at rpmkeyring.c:62 #5 rpmReadPackageFile at package.c:716 #6 cr_package_from_file at /usr/src/debug/createrepo_c-0.1.15/src/parsepkg.c:135 #7 dumper_thread at /usr/src/debug/createrepo_c-0.1.15/src/createrepo_c.c:260 #9 g_thread_proxy at gthread.c:797
Created attachment 706116 [details] File: backtrace
Created attachment 706117 [details] File: cgroup
Created attachment 706118 [details] File: core_backtrace
Created attachment 706119 [details] File: dso_list
Created attachment 706120 [details] File: limits
Created attachment 706121 [details] File: maps
Created attachment 706122 [details] File: open_fds
Created attachment 706123 [details] File: proc_pid_status
Created attachment 706124 [details] File: var_log_messages
Hi Dan, this bug should be already fixed (http://git.fedorahosted.org/cgit/createrepo_c.git/commit/?id=f7b18829b91125ef0993dccdeb0d839bdfb9045e). I thought it is just a memory leak but the bug was evidently more serious. I'll do new createrepo_c build asap. Thank you for the report!
Fixed in version 0.1.16
I'm afraid it's still not fixed: *** glibc detected *** createrepo_c: double free or corruption (fasttop): 0x000000000156a810 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7ca8e)[0x7fbd54349a8e] /lib64/librpmio.so.3(rpmKeyringFree+0x91)[0x7fbd54dbf2e1] /lib64/librpm.so.3(rpmReadPackageFile+0x5d)[0x7fbd54b721fd] /lib64/libcreaterepo_c.so.0(cr_package_from_rpm+0x87)[0x7fbd5654f1a7] createrepo_c(dumper_thread+0xbf)[0x40518f] /lib64/libglib-2.0.so.0(+0x6be22)[0x7fbd56289e22] /lib64/libglib-2.0.so.0(+0x6b605)[0x7fbd56289605] /lib64/libpthread.so.0(+0x7d15)[0x7fbd540b8d15] /lib64/libc.so.6(clone+0x6d)[0x7fbd543bf46d] $ rpm -q createrepo_c createrepo_c-0.1.16-1.fc18.x86_64
Oh, there is a race condition in createrepo_c threads which calls cr_package_from_rpm() simultaneously. cr_package_from_rpm() calls an rpm function rpmReadPackageFile() with one shared transaction object. Obviously, this approach is not thread safe if keyring is used in this transaction object. I've removed keyring creation. This fixes the problem. This solution works with rpm >= 4.8.0-28 (related commit: http://www.rpm.org/gitweb?p=rpm.git;a=commit;h=cad147070e5513312d851f44998012e8f0cdf1e3). createrepo_c-0.1.16-2 fix the problem (http://koji.fedoraproject.org/koji/taskinfo?taskID=5105749)