On Aug 26, 2013, at 5:19 PM, Per Øyvind Karlsen wrote:
> 2013/8/26 Jeffrey Johnson <n3...@me.com>
>
> On Aug 26, 2013, at 3:17 PM, Per Øyvind Karlsen wrote:
>
> > This patch ensures that strings has a null terminator at end, otherwise
> > strings passed to mireRegexec might be missing it.
> >
>
> Is there a specific problem here? DO you have a reproducer?
> I need to it out of my memory how to exactly reproduce, but IIRC the specific
> problem comes from keys from berkeley db with no null terminator, leading to
> trouble when trying to check it's length with strlen()..
> So in order to work around this, memory with room for the additional null
> terminator is allocated with the string copied into.
>
OK. Yes keys returned from an rpmdb have a length and no NUL terminator, by
intent.
Rather trivial to fix, compared to what is actually implemented, ensuring that
a length
is correctly stored/used everywhere.
My guess at the root cause is that you passed 0 as a length (which usually
triggers a lazy strlen) for
some string that you had retrieved from an rpmdb, and then set about fixing the
code by adding a NUL at the point where the symptom appeared.
Since there are still oodles of
#if defined(RPM_VENDOR_MANDRIVA)
code that do not belong "upstream", this also explains why
you see and I do not.
(aside)
BTW, all the
#if defined(RPM_VENDOR_MANDRIVA)
code in RPM needs to be either merged or patched in by Mandriva. I see
no current purpose in carrying "Have it your own way!" divergence, particularly
when I am expected to provide "support" for code that I do not use nor agree
with.
I can also make a savvy guess at where the rpmdb {key,keylen} misuse occurred
because there are many "band-aid" patched retrofits to handle Mandriva EVRD
comparison that need to be done generall
y, not by repeated/iterated rpmdb access,
as most of the band-aids are doing.
> As it's a two year old collection of patches piled up, there's obviously some
> details my memory is rather vague on, but I'll try see if I can come up with
> the reproducer, but I can't make any promises of when that'll be.
Yup, same here.
> The use of alloca tells me that I applied a band-aid here for some
> reason I've long since forgot.
>
> The real problem (and fix) is likely elsewhere, not here, imho.
> Yeah, I seem to recall having the exact same feeling, but maybe the details
> coming from the top of my head might be sufficient for you to both figure out
> and understand the issue, while also coming up with a better solution. :)
>
Retreiving an rpmdb key using a pattern has a supported API that returns
an argv array that is properly NUL terminated.
The core issue that needs to be properly addressed for EVRD support in
ROSA/Mandriva is to generate indices against which the patterns can be applied
using existing library interfaces, rather than carrying around band-aid hackery
for
years whose reproducers and analysis slowly fades away as the temporary
band-aids become
MUSTHAVE scar tissue because of lack of priority and forgetfulness.
I've been through many band-aid cycles in RPM: it takes an order of magnitude
more time and effort to get the code properly implemented than it does to create
the band-aid at
Danger Will Robinson! The universe as we know it is about to be
destroyed by RPM.
that is typical of detected problems late in a distro release cycle that come
in at EMERGENCY
priority.
After almost 3y, I do believe its time to fix the code, not pretend that
band-aids don't exist.
YMMV, everyone's does.
73 de Jeff
> --
> Regards,
> Per Øyvind
