On 31/08/2007, Robert Edmonds <[EMAIL PROTECTED]> wrote:
> Graham Dumpleton wrote:
> > In 411487 it mentions:
> >
> > """So, it seems it's directly related to libmhash2 (as [2] suggests)."""
> >
> > Disabling of mhash module may not be enough if one of the other PHP
> > modules they list in 433038 also use libmhash2 library. Quite possible
> > that one of the crypto libraries use it, or the ldap module mentioned
> > in the mod_python mailing list mail.
> >
> > Can you run ldd on main PHP module and all PHP modules and see which
> > one has a dependency on libmhash2, or any other md5 hash library.
> In the user's last message to the bug report, he includes the contents
> of /proc/.../maps for functioning and malfunctioning apache instances.
> > Basic problem as we understand it is that libmhash2 uses a symbol name
> > which clashes with one used by Python md5 module. Which ever gets
> > loaded first, usually PHP version, takes precedence and since that is
> > not compatible with other package a crash occurs.
> >
> > If it can be determined that it is libmhash2 and then which symbol in
> > it clashes with one in Python md5 module, one or the other could
> > somehow be namespace escaped to avoid the problem.
> Is it possibly some other library than libmhash2?  The only additonal
> cryptography-related DSOs I see present in the user's php instance are:
> /usr/lib/libmcrypt.so.4.4.7
> /usr/lib/php5/20060613+lfs/mcrypt.so
> All the symbols in those DSOs appear to be namespace escaped.

Hmmm, it is worrying that there are so many different crypto libraries
linked in.


Other areas which also have given problems with PHP/mod_python are
shared libraries for expat, MySQL, SSL and sqllite. See later sections


This is for mod_wsgi, but same things can occur with it.

The only way they may possibly work out which is the problem is to
attach a debugger to Apache in single process mode and work out where
it crashes. Instructions on doing this in later sections of:



Reply via email to