On Feb 15, 2011, at 7:27 PM, Mark Hatle wrote: > I disabled the rpmdsFree in the previous chunk of code, and now showrc works > as > expected. >
Hmm odd ... but -v --showrc isn't something I look at
once every 6 months or so.
This is 5.4.0? If so, you likely have the start of an attempt
to fix data races deep in lib/rpmal.c with macro expanded {N,EVR}.
The issue started way back when with you Montevista patch to
permit macros into file paths.
Its been possible to write
Requires: %%{something> > %%{someversion}
by escaping the expansion during a build.
The race is in rpmal.c, which used to have to step into
an iterator in order to trigger an expansion. The critical
paths within rpmtsCheck() malloc'd their data so that
the race (remember, rpmlib is still single-threaded, there
just are not any races during install) did not hurt anything.
In rpm-5.4.0 I modified the rpmns to do a rather tricky bsearch
because that was showing up as a piggy with Cachegrind. The
code kinda has to be right: its one of those
If you miss, you die instantly.
sort of implementations ;-)
And I also added asserts to nail raciness, as well as adding
a Bloom filter for file paths that made a whole lot of nasty
ugly code unnecessary.
There's also #pragma omp annotations, but I don't believe there's
any "production" usage except in lib/verify.c. Grep for #pragma
rpmio/rpmio_internal.h and lib/verify.c should be the only
multi-threaded code paths in rpm-5.4.0.
Also 5.4.0 should be almost identical to 5.3.8 still, try
cvs diff -r rpm-5_3_8-release -r rpm-5_4_0-release
if worried.
Meanwhile back to rpmdsRpmlib ...
> In lib/rpmrc.c
>
> @@ -1216,11 +1229,15 @@
> if (DNEVR != NULL)
> fprintf(fp, " %s\n", DNEVR+2);
> }
> +#if 0
> (void)rpmdsFree(ds);
> ds = NULL;
> +#endif
> fprintf(fp, "\n");
> }
> +#if 0
> PRCO = rpmdsFreePRCO(PRCO);
> +#endif
> }
>
> if (rpmIsVerbose()) {
>
>> I'm currently using rpm-5.4.0, and I've encountered a few issues.. however
>> during this I'm trying to diagnose loading of certain files using --showrc.
>> But
>> when I do, I get a segfault.
>>
>> Looking at valgrind output I get:
>>
>> ==3492== Invalid read of size 8
>> ==3492== at 0x53E862A: rpmioGetPool (rpmmalloc.c:223)
>> ==3492== by 0x4E73A9B: rpmdsGetPool (rpmds.c:196)
>> ==3492== by 0x4E76209: rpmdsMerge (rpmds.c:950)
>> ==3492== by 0x4E782B2: rpmdsRpmlib (rpmds.c:1567)
>> ==3492== by 0x4E88966: rpmShowRC (rpmrc.c:1243)
>>
>> And further items that seem to indicate I've got memory corruption.
>>
>> if (rpmIsVerbose()) {
>> fprintf(fp, _("Features provided by rpmlib installer:\n"));
>> xx = rpmdsRpmlib(&ds, NULL);
>
> Within rpmdsRpmlib, it does a merge of ds & the new internal ds from the
> rpmlib
> instantiation. This is what is triggering the valgrind messages, but again
> I'm
> at a loss to figure out where the real bug is.. but based on the above it
> seems
> like it's in the merge code.
>
The real bug is likely that there's an attempt to be squeaky clean with
valgrind.
There's likely dueling free's from a lazily instantiated and refcounted
rpmds object for rpmlib(...) dependencies.
Adding --rpmdsdebug should show the "++" and "--" where references are
taken, as well as a display of the elements in a rpmds when iterating.
So removing one of the dereferences (like you've done above) is gonna
be the right fix even if it needs to be done differently.
> --Mark
>
>> ds = rpmdsInit(ds);
>> while (rpmdsNext(ds) >= 0) {
>>
>> the rpmdsRpmlib is the function causing the issue. Prior to this ds is
>> freed,
>> and I'm wondering if that is causing the problem. But I'm not sure how to
>> diagnose any of the memory pool functions or even if Merge is doing the right
>> thing. Any suggestions would be appreciated.
Adding --rpmdsdebug should show the "++" and "--" where references are
taken, as well as a display of the elements in a rpmds when iterating.
If with --showrc, remember that there's an exit within showrc processing,
which means that this "works"
rpm -v --rpmdsdebug --showrc
and this does not
rpm --showrc -v --rpmdsdebug
I.e. the exit is taken before the "-v --rpmdsdebug" options are processed.
Dunno whether that's worth fixing -- the implemented behavior is goofy --
for --showrc and --querytags.
73 de Jeff
>>
>> --Mark
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
smime.p7s
Description: S/MIME cryptographic signature
