On Sun, Dec 15, 2002 at 03:19:04PM -0500, Daniel Jacobowitz wrote: > On Sun, Dec 15, 2002 at 02:02:38PM -0600, Steve Langasek wrote: > > On Sun, Dec 15, 2002 at 11:50:23AM -0800, Jeff Bailey wrote: > > > On Sun, Dec 15, 2002 at 12:49:56PM -0600, Steve Langasek wrote: > > > > I've made some progress into figuring out the source of the glibc 2.3, > > > > apache, php4, php4-imap segfaults. I suspect that php4 and openssl are > > > > ultimately at fault (at least, a change with regards to these two > > > > packages seems to correct the error), but I'm not certain, so I'm > > > > sending a follow-up to the bug report to get feedback before reassigning > > > > back to PHP4. > > > Wow. If it does turn out to be a php4 problem, aj has told me that it's > > > okay to fill our conflicts lines with other packages so whoever winds up > > > with this bug, please make sure that debian-glibc@lists.debian.org knows > > > which version to conflict against. > > If no one on the glibc side can point to a bug in glibc 2.3 that would > > have caused the libcrypto dependency to suddenly become a problem, then > > I imagine this is what we'll do. I'm still curious to know what changed > > between 2.2 and 2.3, so if anyone has any ideas... > I'm exceedingly suspicious here; it would be nice to figure out if this > is a bug of the dynamic linker, since that seems likely from your > description. I agree, it does sound like a bug in the dynamic linker. In order for the main Apache binary to have referenced a symbol in libcrypto.so (let's assume it's crypt()), the linker would have had to either search libcrypto.so before searching libcrypt.so, despite the latter having been loaded first; or not find anything within libcrypt.so that met its criteria. The only possible way I can imagine it makes sense for this to happen is if php4 is linked with -Bsymbolic (which it does not appear to be); PHP4 calls crypt() while loaded the first time, causing the symbol name to be resolved to the libcrypto.so version; the linker caches this because Apache needs crypt() as well; and things go downhill. Does that sound about right? -- Steve Langasek postmodern programmer
Attachment:
pgpbtRx_h0A2j.pgp
Description: PGP signature