[Python-modules-team] Bug#433038: Debian bug#433038: mod_python collides with mod_php5

[Graham Dumpleton]

On 31/08/2007, Robert Edmonds <edmonds at debian.org> 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.

/lib/i686/cmov/libcrypt-2.6.1.so
/usr/lib/i686/cmov/libcrypto.so.0.9.8
/usr/lib/libgcrypt.so.11.2.3
/usr/lib/libk5crypto.so.3.1
/usr/lib/libmcrypt.so.4.4.7
/usr/lib/php5/20060613+lfs/mcrypt.so

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

  http://code.google.com/p/modwsgi/wiki/ApplicationIssues

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:

  http://code.google.com/p/modwsgi/wiki/DebuggingTechniques

Graham