On Mar 1, 2011, at 2:45 PM, Jeff Johnson wrote:
>
> 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.
>>
>
One last note:
Here's the valgrind spewage from the pojy bug report:
=444== Invalid read of size 1
==444== at 0x694C5DC: regcomp (regcomp.c:502)
==444== by 0x86F139B: mireRegcomp (mire.c:364)
==444== by 0x6E46E22: defaultMachine (rpmrc.c:475)
==444== by 0x6E4743B: rpmSetMachine (rpmrc.c:841)
==444== by 0x6E475B3: rpmRebuildTargetVars.clone.1 (rpmrc.c:925)
==444== by 0x6E47DFA: rpmReadConfigFiles (rpmrc.c:1115)
==444== by 0x52E45A6: zypp::target::rpm::librpmDb::globalInit() (in
/usr/lib/libzypp.so.810.1.0)
==444== by 0x52C6990: zypp::target::rpm::RpmDb::RpmDb() (in
/usr/lib/libzypp.so.810.1.0)
==444== by 0x52FC023:
zypp::target::TargetImpl::TargetImpl(zypp::filesystem::Pathname const&, bool)
(in /usr/lib/libzypp.so.810.1.0)
==444== by 0x5412F08: zypp::Target::Target(zypp::filesystem::Pathname
const&, bool) (in /usr/lib/libzypp.so.810.1.0)
==444== by 0x5425BA3:
zypp::zypp_detail::ZYppImpl::initializeTarget(zypp::filesystem::Pathname
const&, bool) (in /usr/lib/libzypp.so.810.1.0)
==444== by 0x5420E2E:
zypp::ZYpp::initializeTarget(zypp::filesystem::Pathname const&, bool) (in
/usr/lib/libzypp.so.810.1.0)
==444== Address 0xb2a9f88 is not stack'd, malloc'd or (recently) free'd
==444==
The only way that backtrace can happen (that I can see) is if RPM, not zypper,
is mis-compiled
using an unfixed (to redefine colliding symbols) "system: PCRE with
#include <pcreposix.h>
which leaves you two choices:
1) fix you "system" PCRE <pcreposix.h>
2) build --with-pcre=internal
>From what I know of zypper (mostly libsatsolver and tools), the code rips
>everything
out-of-an-rpmdb and uses as little as possible from RPM libraries. But I haven't
looked for 2+ years.
hth
73 de jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
