On Mar 1, 2011, at 2:20 PM, Mark Hatle wrote:
> I think jbj might have figured out the problem. Zypper is not using pcre, but
> is instead causing mire to use the system regex.
>
> I made some local changes in an attempt to point the #include of regex.h in
> mire
> with a #error. I'm in the process of building both RPM and Zypper now to see
> if
> this causes a build failure -- if it does, we need to figure out a Zypper
> solution because it's bringing in mire.h.
>
If you can show me the Zypper code that's trying to use miRE, I can
likely suggest a clean fix.
The "traditional" use of mire was tied to
rpm -qa foo*
as a selection filter on packages returned from a sequential
iteration through Packages.
The problem there is that *its Pig Slow* to load every
installed header just to apply a pattern to NVRA.
Its equally opig slow on @rpm.org or @rpm5.org code
(though @rpm5.org will be faster than @rpm.org for other reasons ;-)
But _NOT_ doing
#include <mire.h>
and once again _NOT_ installing
/usr/include/rpm/mire.h
(and thereby implicitly exporting a very messy API issue)
is The Right Thing To Do.
Anything that <mire.h> can also be done in zypper without
a whole lotta work.
Can you snip out and send along the zypper usage case for <mire.h> please?
73 de Jeff
> --Mark
>
> On 3/1/11 1:15 PM, pinto.e...@gmail.com wrote:
>> Hi, i have checked mire.c and there is none difference from 5.3 and 5.4. So
>> perhaps a autofu issue is possible, difficult that i can do a MandrivaUpdate
>> without a problem on cokker with a such apparently evident problem with
>> 5.3.6. Can you post your configure invocation, configure log. Regards
>> -----Original Message-----
>> From: Paul Eggleton
>> Sent: 01/03/2011, 17:04
>> To: rpm-devel@rpm5.org
>> Subject: librpmio memory allocation issue
>>
>>
>> Hi there,
>>
>> In Poky we're currently seeing a crash of "zypper search" in conjunction
>> with
>> rpm 5.4.0 [1]. Using valgrind I tracked the issue down to rpmio/mire.c line
>> 361:
>>
>> mire->preg = xcalloc(1, sizeof(*mire->preg));
>>
>> If I hack this line to specify 64 as the size (the expected sizeof(regex_t)
>> for x86_64, as opposed to 24 reported by valgrind) then the crash disappears
>> and valgrind stops reporting invalid memory accesses.
>>
>> I don't have much knowledge of the rpm codebase, but a bit of header
>> grepping
>> shows me that libpcre's pcreposix.h has a regex_t which differs quite
>> considerably from regex_t in regex.h (and matches the smaller size reported
>> by
>> valgrind), and therefore I strongly suspect that the culprit is that pcre's
>> regex_t is being used when allocating the struct in mire.c which is then
>> passed to regcomp. FWIW we are enabling pcre support at configure time.
>>
>> I could hack this to work, but since we may have dueling headers here the
>> solution might not be trivial. Any suggestions?
>>
>> Thanks,
>> Paul
>>
>> [1] http://bugzilla.pokylinux.org/show_bug.cgi?id=721
>>
>
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
