[mod_python] null pointer to PyObject_CallMethod

On 25/03/07, Christian Boos <cboos at neuf.fr> wrote:
> Graham Dumpleton wrote:
> > ..... Confirm in your application that main interpreter is being used
> > by dumping out
> > 'apache.interpreter' or 'req.interpreter'.
>
> Interesting, I can see some use for that in Trac, as running in
> sub-interpreters also proves to be problematic for us.

This comment suggested you might be involved with the development of
Trac. Is that the case or are you just a dedicated user?

> That's a known problem together with the Subversion bindings,

But which isn't as far I have been able to work out because mod_python
has bugs as some still occasionally suggest, but because of how the
Subversion bindings are implemented. :-(

> but seeing
> now that weird error reported for cx_Oracle and your suggestion, I
> wonder if some other, equally weird error involving mod_python and
> mysql-python couldn't be explained by the same cause (see
> http://trac.edgewall.org/ticket/5012).

Looking at MySQLdb module, the error in that ticket relating to
'connect' not being found within the module looks to me totally
unrelated to issues as to what sub interpreter an application may be
running under within mod_python. This is because MySQLdb is a Python
module and 'connect' is just an attribute of that and should be
unchanging. The actual C code component of MySQLdb is at a lower level
and shouldn't really come into it.

What I would be focusing more on with that ticket is the code in
trac/db/mysql_backend.py at:

    def __init__(self, path, user=None, password=None, host=None,
                 port=None, params={}):
        import MySQLdb

        ....

        if (self._mysqldb_gt_or_eq((1, 2, 1))):
            cnx = MySQLdb.connect(db=path, user=user, passwd=password,
                                  host=host, port=port, charset='utf8')
        else:
            cnx = MySQLdb.connect(db=path, user=user, passwd=password,
                                  host=host, port=port, use_unicode=True)

Given that the import of MySQLdb is done within the function scope, I
presume it is in some way evaluated each time the function is called
and reference obtained via import mechanism. That the error comes up
sometimes suggests that the import mechanism is throwing back an empty
module reference, or the wrong module altogether and thus why
'connect' cannot be found.

What I would have done would have been to move that import to global
scope and see if the problem goes away, or fiddle the code to add a
try/except block and when the error occurs dump out as much
information as possible about what module is bound to MySQLdb
reference to try and identify whether it truely is MySQLdb or
something totally different.

In short, applying some basic debugging techniques to the problem in
that ticket should help to track it down if the original reporter was
willing to look into it properly.  Unfortunately most people just want
a quick fix, preferably from some one else. ;-)

Graham