Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 920795 - createrepo_c segfaults
Summary: createrepo_c segfaults
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: createrepo_c
Version: el6
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Tomas Mlcoch
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-03-12 18:26 UTC by Dennis Gilmore
Modified: 2013-03-29 21:28 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-03-29 21:28:05 UTC
Type: Bug

Attachments (Terms of Use)

Description Dennis Gilmore 2013-03-12 18:26:00 UTC
Description of problem:
when using createrepo_c on the arm koji hub we saw large numbers of createrepo failures where createrepo_c would segfault

createrepo_c[3443] general protection ip:7fd6b67ce6ec sp:7fffafb96548 error:0 in[7fd6b6753000+18a000]
createrepo_c[3729] general protection ip:7f7ddda0a6ec sp:7fffc7f97188 error:0 in[7f7ddd98f000+18a000]

Version-Release number of selected component (if applicable):

How reproducible:
run createrepo_c on the full fedora arm buildroot tree 

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Tomas Mlcoch 2013-03-14 07:14:02 UTC
Hi Dennis,
could you please try the newest createrepo_c epel6 build?
The version 0.1.16-2 should be already in stable:

This bug is maybe related with and in 0.1.16 the bug should be fixed.

Note: createrepo_c-0.1.16 needs rpm >= 4.8.0-28 (this shouldn't be problem in epel)

Comment 2 Dan Horák 2013-03-24 12:37:44 UTC
createrepo_c-0.1.16-2.el6.x86_64 fails the same way on the s390x hub, it fails when run from koji, not from command line (it has different output dir)

Comment 3 Dan Horák 2013-03-24 12:40:01 UTC
and it worked fine in quite old rhel6 (cca 6.1) and started to crash after update to 6.4

Comment 4 Dan Horák 2013-03-24 15:14:23 UTC
(gdb) set args -vd -o /tmp/createrepo -u -i /mnt/koji/repos/f19-build/165457/s390/pkglist -g /mnt/koji/repos/f19-build/165457/groups/comps.xml --update --skip-stat /mnt/koji/packages/
(gdb) run
15:09:10: Adding pkg: /mnt/koji/packages/pcp/3.6.10/2.fc19.1/s390/perl-PCP-LogImport-3.6.10-2.fc19.1.s390.rpm
15:09:10: Adding pkg: /mnt/koji/packages/pcp/3.6.10/2.fc19.1/s390/perl-PCP-MMV-3.6.10-2.fc19.1.s390.rpm
15:09:10: Package count: 27469
Directory walk done - 27469 packages
C_CREATEREPOLIB: Critical: cr_load_xml_files: Parse error at line: 96956 (not well-formed (invalid token))
C_CREATEREPOLIB: Critical: cr_metadata_load_xml: Error encountered while parsing
15:09:19: Old metadata from /tmp/createrepo/ - loading failed
Loaded information about 0 packages
15:09:19: Copy groupfile /mnt/koji/repos/f19-build/165457/groups/comps.xml -> /tmp/createrepo/.repodata/comps.xml

Program received signal SIGSEGV, Segmentation fault.
0x0000003da86480ac in vfprintf () from /lib64/
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-7.el6_0.x86_64 cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 db4-4.7.25-17.el6.x86_64 elfutils-libelf-0.152-1.el6.x86_64 expat-2.0.1-11.el6_2.x86_64 file-libs-5.04-15.el6.x86_64 glib2-2.22.5-7.el6.x86_64 glibc-2.12-1.107.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.1.x86_64 libacl-2.2.49-6.el6.x86_64 libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64 libcom_err-1.41.12-14.el6.x86_64 libcurl-7.19.7-35.el6.x86_64 libgcc-4.4.7-3.el6.x86_64 libidn-1.18-2.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 libssh2-1.4.2-1.el6.x86_64 libxml2-2.7.6-12.el6_4.1.x86_64 lua-5.1.4-4.1.el6.x86_64 nspr-4.9.2-1.el6.x86_64 nss- nss-softokn-freebl-3.12.9-11.el6.x86_64 nss-util- openldap-2.4.23-32.el6_4.x86_64 openssl-1.0.0-27.el6_4.2.x86_64 popt-1.13-7.el6.x86_64 rpm-libs-4.8.0-32.el6.x86_64 sqlite-3.6.20-1.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) where
#0  0x0000003da86480ac in vfprintf () from /lib64/
#1  0x0000003da8701e6c in __vasprintf_chk () from /lib64/
#2  0x0000003daa26dd2b in g_vasprintf () from /lib64/
#3  0x0000003daa25a480 in g_strdup_vprintf () from /lib64/
#4  0x0000003daa242fe0 in g_logv () from /lib64/
#5  0x0000003daa243413 in g_log () from /lib64/
#6  0x0000003db4a0aafe in cr_metadatalocation_free (ml=0x13bab10) at /usr/src/debug/createrepo_c-0.1.16/src/locate_metadata.c:45
#7  0x0000000000404724 in main (argc=2, argv=0x7fffffffe338) at /usr/src/debug/createrepo_c-0.1.16/src/createrepo_c.c:817

I get this error when run against an existing repodata in /tmp/createrepo

Comment 5 Dan Horák 2013-03-24 15:18:47 UTC
and I guess it's a non-UTF8 encoded character in the metadata (other.xml)

Comment 6 Dan Horák 2013-03-24 19:07:29 UTC
It must really be a problem with wrong encoding, when createrepo_c is run with old repodata prepared by createrepo, it finishes correctly, but writes bad xml file. The problem appears on metadata (changelog) for the gdmap package in other.xml.

Comment 7 Dennis Gilmore 2013-03-25 14:21:47 UTC
it may be because of the encoding in the spec file,  but createrepo_c needs to cope with it. its not an issue for createrepo

Comment 8 Dennis Gilmore 2013-03-25 14:46:03 UTC
the character in question seems to be ä which is utf-8 createrepo_c needs to support utf-8

Comment 9 Tomas Mlcoch 2013-03-25 14:52:59 UTC
Hi, thank you for a such detailed report, you are right.
There were two bugs:

The first one could lead to a SIGSEGV while parsing a non valid XML. (fixed in:

The second bug was an omitted sanitation of encoding during XML generation. It could leads to invalid characters in output XML. (fixed in:

Could you please try the scratch build:

Comment 10 Dan Horák 2013-03-25 15:26:02 UTC
Thanks, the issue I saw is gone, going to set createrepo_c again in production.

Comment 11 Fedora Update System 2013-03-28 08:54:03 UTC
createrepo_c-0.1.17-1.el6 has been submitted as an update for Fedora EPEL 6.

Comment 12 Fedora Update System 2013-03-29 21:28:07 UTC
createrepo_c-0.1.17-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.