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
This helps a lot, with the patching of "system" PCRE, the problem seems gone. The RPM we are using is rpm-5.4.0, which doesn't have an internal pcre shipped, so I diffed the "system" header with the internal header, and saw the "#define regcomp pcreposix_regcomp" artifact. It's then much clearer to understand what actually happened, regex_t from pcreposix.h is used bug regcomp from libc is what get called at runtime, that causes the failure. Interestingly, this patch is also found in Debian, but no versions of vanilla PCRE. I tried to find some original discussion on the issue, but got no meaningful result, is there any references? And why PCRE upstream is sticking to this? > > > > 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. Doesn't know much about zypper internals, but the issue above is triggered with only NULL passing around. Thanks, Qing ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
