Comment 2 for bug 651509

AFAICT the memleak comment in rpmHeaderGetEntry() refers to the fact that for summary, description and group it returns a malloced string of RPM_STRING_TYPE which headerFreeData() doesn't free. The python bindings "know" this funky little detail and take care of it, and at least I'm not able to reproduce leakage from that.

Looking at the dumps in bug 173424, it seems to me more like setenv() related memory corruption, not leak. The rpm tag translation fiddles LANGUAGE environment variable back and forth for each translated item, and increments _nl_msg_cat_cntr on each change. On a very busy box, I could imagine _nl_msg_cat_cntr possibly wrapping around and maybe something can't handle that - I dunno, that's just a wild guess but there's all sorts of things piled up in here, for example perl doing something in this area:

==4465== Invalid free() / delete / delete[]
==4465== at 0x1B8FF382: free (vg_replace_malloc.c:235)
==4465== by 0x1BFFA0DE: Perl_safesysfree (in
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so)
==4465== by 0x1BFFDC07: Perl_my_setenv (in
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so)
==4465== by 0x1BDF9C0A: mod_perl_pass_env (perl_config.c:207)

To put it another way, obviously the rpm translation code is causing problems (the way it works is pretty wicked), but whether that's the bug or is it just triggering problems elsewhere is not that clear.

In the meanwhile, there's a much less intrusive way to disable the translations than having spacewalk conflict with specspo:

rpm.delMacro("_i18ndomains")

I'm not familiar with spacewalk codebase so can't suggest where exactly to put it, but somewhere after rpm module has been loaded is will do.