[ZODB-Dev] strange testConnection error

Tim Peters tim at zope.com
Tue Mar 15 14:47:12 EST 2005


[Tim Peters]
....
>> Google turns up lots of reports of problems with restricted execution
>> mode under mod_python ...

[John Belmonte]
> Reading the following, it sounds like mod_python is the culprit:
>
>   http://www.modpython.org/pipermail/mod_python/2005-January/017129.html
>
> It's disturbing that no one responded to that post.  I guess I'll have to
> give the development version of mod_python a try, or revert to an older
> version.

Or ask again on the mod_python list?  There are records of problems going
back at least to 1998, s/mod_python/pyapache/, but I know almost nothing
about those, and truly nothing about their internals.

If they start a new interpreter from time to time (there's a Python C API
for doing that, inaccessible from Python-level conde, and unused by anything
in the Python, Zope, or ZODB distributions) "for security reasons", that
might explain it.  Then the new interpreter has its own distinct copies of
the sys module, the sys.modules dict, and the sys.path list.  I'm wondering
about that because "restricted execution mode" _alone_ isn't enough to
account for the ImportError you saw.  It must also be the case both that
copy_reg wasn't in sys.modules, and that copy_reg.pyc wasn't found on
sys.path:

- If copy_reg was in sys.modules, the import attempt would have succeeded.

- If copy_reg.pyc was found on sys.path, then in restricted execution
  mode the attempt to import it would have died with a different
  exception:

RuntimeError: cannot unmarshal code objects in restricted execution mode

That wouldn't have helped you either, of course; the point is that because
you saw ImportError instead, we can deduce that sys.modules and sys.path
were both in unexpected states, and creating a new interpreter object at the
C level is the most plausible way to get into _that_ kind of trouble.



More information about the ZODB-Dev mailing list