On Mar 1, 2011, at 2:33 PM, Mark Hatle wrote:
> On 3/1/11 1:27 PM, Jeff Johnson wrote:
>>
>> 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.
>
> I am not finding any direct inclusions of "miRE" within Zypper or libzypper.
> However, I am finding an inclusion of regex.h within libzypper.
>
If the *pig slow* load every iteration is in play in zypper
(I hope note: mls is a smart coder usually), then this
is the API that must be used to set a pattern on a match iterator:
/** \ingroup rpmdb
* Add pattern to iterator selector.
* @param mi rpm database iterator
* @param tag rpm tag
* @param mode type of pattern match
* @param pattern pattern to match
* @return 0 on success
*/
int rpmmiAddPattern(/*@null@*/ rpmmi mi, rpmTag tag,
rpmMireMode mode, /*@null@*/ const char * pattern)
/*@globals rpmGlobalMacroContext, h_errno, internalState @*/
/*@modifies mi, mode, rpmGlobalMacroContext, internalState @*/;
I've forgot the older "traditional" name and lost track of @rpm.org.
The "leakage" that forces
#include <mire.h>
is solely to get the rpmMireMode enumeration. You can easily just pass
the handul of modes as integers and stub out the rpmMireMode typedef
to avoid a whopping amount of pain here.
I'd move rpmMireMode Somewhere Else Instead except it isn't clear
where that SomeWhere SHOULD be and any change -- paricularly repeated changes --
in an API is a worser solution than busted (but known) status quo ante.
> I am still trying to track down the call order, but if I had to guess.. zypper
> is calling into RPM with a regex object, which is getting fed to mire
> (internally) and because the sizes are different we're getting a failure of
> some
> type.
>
k.
There's no API (I can think of) where a regex can be passed into RPM.
But that's never stopped anyone from doing what was needed with RPM.
The calls I see at the bug report are all on rpmlib initialization.
But its usually rpmMireMode that drags in
#include <mire.h>
73 de Jeff
>
>
>> 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
>
> ______________________________________________________________________
> 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
