"XXX undetected error" in python_d.exe

Michael Hudson mwh at python.net
Fri Dec 14 05:43:48 EST 2001


Courageous <jkraska at san.rr.com> writes:

> How am I supposed to interpret this error when it is printed
> by the Python interpreter? What information is it telling me?
> This appears to be a feature of newer (2.2?) interpreters in
> debug build only.

I think it means some opcode evaluated and failed to maintain the
required invariant mentioned at the top of the Big Switch in ceval.c:

        /* BEWARE!
           It is essential that any operation that fails sets either
           x to NULL, err to nonzero, or why to anything but WHY_NOT,
           and that no operation that succeeds does this! */

At a guess, the opcode that does this is CALL_FUNCTION, and you have
an extension module somewhere that fails to return NULL when it sets
an exception.

> I've seen it flag off on reads from zero memory, so I know it's
> not just an ordinary internal catch. It almost seems as if the
> Python interpreter is catching SIGSEGV or something like that,
> only I can find no code to enable such shenanigans.

It's not that.

> I'm having a problem with it under VC6.0, because when it throws
> off, it seems to cause the interpreter to exit, even when a serious
> error has occured in extension modules I am writing/
> adapting. What's bizarre is that this seems inconsistent, and I
> can't identify any code that would allow Python to intercept memory
> faults under windows.

I have nasty memories of debugging memory faults under Windows,
specifically of them not always landing me in the debugger.  ISTR some
dialog box that allowed me to get memory exceptions to "Always Stop"
(and gibbering with fright that this wasn't the default).  I could
have a faulty memory here (and it was VC5).

HTH,
M.

-- 
  ARTHUR:  Don't ask me how it works or I'll start to whimper.
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 11



More information about the Python-list mailing list