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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4