[Python-Dev] Fw: Access violation when no memory

[Fred L. Drake, Jr.]

Vladimir Marangozov writes:
 >    There are two possible fixes, and I'm not sure which one is better:
 > 
 >    a) Fix the Instance_New code, by freeing the instance on inst->in_dict
 >       allocation failure (without decref'ing the instance).

  I think this is the right one; this *shold* be all that's ever
needed, and isolates the check to the cod ethat can experiance
failure.

 >    b) Fix the dealloc code, by checking whether in_dict is not NULL
 >       before proceeding with the __del__ finalization logic.

  This protects against bad C code elsewhere that makes a mess of
existing objects by stepping around the API (such as by setting
inst->in_dict to NULL).  I'm not sure we want to protect against that
since it could mask bugs (I doubt anyone would do that deliberatly, so
I feel safe calling it a bug!).

 >    Opinions?

  And for free!  So infer what you will about their worth.  :)

 > 2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on
 >    low-memory conditions. They are pushed on the stack, then popped with
 >    a segfault.  The only reasonable behavior I get, after some testing,
 >    is by setting the tb and exc to Py_None if any of them is NULL before
 >    pushing them onto the stack. The program succeeds or the process is
 >    killed by the OS (tested on Linux).
 > 
 >    However, I'm not sure that setting tb and/or exc to Py_None, if NULL,
 >    makes any sense and won't cause side effects.

  This doesn't seem like a situation where you'd be masking some other
kind of bug by using Py_None, and it avoids the core dump.  Since
you're not masking anything, I'd go ahead and use Py_None here.


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member