[Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

[Panu Matilainen]

On 10/03/2017 12:12 AM, Thierry Vignaud wrote:
> On 2 October 2017 at 23:06, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
>> Also this new rpm introduced segfault regressions in both RPM4 & urpmi
>> testsuites
>> See attached gdb traces in BUG*.txt
>> valgrind seems to hint about invalid writes/reads
>> See you
> 
> The urpmi issue is when checking bogus pkgs.
> The RPM4 issue is when traversing the transaction (not the rpmdb)
> Attached are the valgrind outputs
> 

So we have stuff like

==14087== Invalid write of size 4
==14087==    at 0x103AA6DD: headerUnlink (header.c:188)
==14087==    by 0x103AA6DD: headerFree (header.c:194)
==14087==    by 0xFF69314: XS_RPM4__Header_DESTROY (RPM4.xs:890)
==14087==    by 0x3F512E2C40: Perl_pp_entersub (pp_hot.c:4231)
==14087==    by 0x3F5125551E: Perl_call_sv (perl.c:2848)
==14087==    by 0x3F512E7C09: S_curse (sv.c:6987)
==14087==    by 0x3F512E84F7: Perl_sv_clear (sv.c:6591)
==14087==    by 0x3F512E898D: Perl_sv_free2 (sv.c:7088)
==14087==    by 0x3F513182E6: UnknownInlinedFun (inline.h:200)
==14087==    by 0x3F513182E6: Perl_free_tmps (scope.c:212)
==14087==    by 0x3F512DAD74: Perl_pp_nextstate (pp_hot.c:52)
==14087==    by 0x3F512DAA55: Perl_runops_standard (run.c:41)
==14087==    by 0x3F5125D236: S_run_body (perl.c:2524)
==14087==    by 0x3F5125D236: perl_run (perl.c:2447)
==14087==    by 0x400C79: main (perlmain.c:123)
==14087==  Address 0xffeffef8c is on thread 1's stack
==14087==  396 bytes below stack pointer

...and all the failures are around headerFree(), but none of the traces 
go into rpm itself, so I dont really know what does "traversing the 
transaction" actually mean. But the problem is simply with perl-RPM4 and 
urpmi passing uninitialized variables to headerFree().

What changed in rpm is that rpmReadPackageFile() no longer does this as 
the first thing:

     if (hdrp)
         *hdrp = NULL;

Ie if you pass an uninitialized pointer as hdrp, it remains 
uninitialized unless rpmReadPackageFile() returns with a success code.
Which is how I think it should be, but it does deserve a release note on 
the changed API.

So the moral of the story is basically: if you depend on your variables 
being initialized, initialize them by yourself. It's a good practise anyway.

	- Panu -