[Zope3-dev] error return without exception set

[Guido van Rossum]

> I can reproduce the following error on standard-output:
> 
> 
> 2003-02-23T13:24:19 ERROR SiteError Error while reporting an error to 
> the ErrorReportingService service
> Traceback (most recent call last):
>    File "Zope3/src/zope/app/publication/zopepublication.py", line 225, 
> in handleException
>      errService = queryService(object, ErrorReports)
>    File "Zope3/src/zope/component/__init__.py", line 43, in queryService
>      sm = queryServiceManager(context)
>    File "Zope3/src/zope/component/__init__.py", line 32, in 
> queryServiceManager
>      return getServiceManager(context)
>    File "Zope3/src/zope/component/__init__.py", line 28, in 
> getServiceManager
>      return getServiceManager_hook(context)
>    File "Zope3/src/zope/app/component/hooks.py", line 44, in 
> getServiceManager_hook
>      return ContextWrapper(
>    File "Zope3/src/zope/security/checker.py", line 159, in proxy
>      checker = getattr(value, '__Security_checker__', None)
> SystemError: error return without exception set
> 
> 
> This doesn't appear to be a problem with the proxy C code, because the 
> 'value' in getattr(value, '__Security_checker__', None) is not at all 
> wrapped.
> 
> Unfortunately, I cannot produce a small stand-alone test case.
> 
> Would anyone savvy in python at the C level like to help me track down 
> what is happening?

Are there any 3rd party C extensions involved?

Do you know the type of 'value'?  The C code implementing its getattr
is the most likely cause.

Does it also happen with Python 2.3a2?  (I bet not -- though this
doesn't mean it's fixed there.)

You should start by building a debug version of Python (make clean;
./configure --with-pydebug; make) and then use that to rebuild all of
your Zope 3 C code (make clean; make PYTHON=path-to-debug-python).

Then all sorts of things could happen.  Ideally, it would show you in
more detail where the problem is.  But since the bug is elusive, it's
probably dependent on the content of some random uninitialized memory,
and that means it could also just go away: in debug mode, memory
layout is different.  Or it could be caused by memory corruption
earlier, and then the debug mode could trap the corruption earlier --
or not.

If you can't reproduce it in debug mode, go back to regular mode, and
put a gdb breakpoint on the line that generates that SystemError (it's
in Python/ceval.c).  If debug mode does reproduce the bug but doesn't
help you find it, do this in debug mode (gdb is more useful with a
debug Python, because the line numbers aren't scrambled like they are
by the non-debug optimizer).  That would at least show in more detail
which operation really caused the problem, and we might be able to
take it from there.

Assuming this depends on the data in your Data.fs, you could ship me
the Data.fs and additional files and I might be able to reproduce it
here.

--Guido van Rossum (home page: http://www.python.org/~guido/)