createrepo fails with headerRead failed message

Question

I execute

createrepo -v --update epel-dir/

and at package number 14173, the process fails with a Python stack trace complaining that:

headerRead failed: Header sanity check: OK

So, I thought okay, I downloaded a bad RPM file:

mv epel/borked-1.2.3.x86_64.rpm Bad

after moving it to a temp directory and re-runing createrepo:

createrepo -v --update epel-dir

the same error hits on the next file. And the next, and the next ...

So, I thought maybe it's having a problem with too many files in the repository (roughly 23k - it doesn't strike me as a lot, but I've never built a local repo). I moved roughly half the files to another directory:

mkdir epel2
mv epel-dir/[n-z]* epel2

I then ran createrepo on epel2, and had no problems. So, I thought maybe the repodata cache is bad?

rm -rf epel-dir/repodata epel2/repodata

and the re-ran createrepo on epel-dir and epel2 -- success on epel2 with ~10k files and failure at around file 7745 on epel-dir directory which has about 12k files.

Then, since I wanted to ensure the files themselves aren't the problem:

createrepo -v --update Bad/

Which succeeds without any errors on the half dozen or so files. I'm not sure what the problem is, nor where to look -- I don't know from RHEL/rpm, so any help/suggestions would be great.

UPDATE:

I've tried to summarize the Python stack trace here:

error: rpmts_HdrFromFdno: headerRead failed: Header sanity check: OK
Trace....

  file dumpMetaData.py line 97 in returnHdr
   hdr = hdrFromFdno(fdno)
SystemError: error return without exception set

Answer 1

So, I narrowed down the 22k files to one in particular which stack dumps.

I probably could have found this sooner except I didn't realize until I only had a singleton file -- createrepo doesn't output any processing info until AFTER it completes the header check info. Since that failed, the rpm file listed above the error WAS NOT the file which failed, but the file before, the failed file name was never output. I only noticed it until I had (tediously) narrowed it down to a single file, and then saw no file info output preceding the stack trace. I'll mark this as a bug! as well as the error handling in my question.

So, the problem file turned out to be libmicrohttp-doc-0.4.6-1.el5.x86_64.rpm.

I'm not sure which mirror it came from - it's old, at someone else was pulling repo's then; however the version which fails compared with a version pulled down from Fedora have different MD5 values ... so something seems amiss with the version I have. I'm marking the result answered because without fixing the Python there isn't anything else I can learn.

Thanks to @Bratchley (per my comment I'll try and get the stack trace).