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