Author dmalcolm
Recipients dmalcolm
Date 2010-07-14.23:50:44
SpamBayes Score 0.00278661
Marked as misclassified No
Message-id <1279151450.93.0.973335817084.issue9263@psf.upfronthosting.co.za>
In-reply-to
Content
Modules/gcmodule.c contains various assertions which can fail due to reference counting errors elsewhere in either python, or an extension module.  These can be difficult to track down.

In the hope of maximizing the information from crash reports, the attached patch (against py3k) introduces a new assertion macro to Objects/object.h and Objects.c, which provides a richer debug message.  In particular, it identifies which object has the issue, and can more clearly spell out the problem.

The patch replaces all uses of assert() in Modules/gcmodule.c for which a specific object has an issue (e.g. bogus reference count).

The implementation may play somewhat fast-and-loose with rules about object invariants: you might have an only partially valid object, but the process is about to abort, so it seems acceptable to try to glean extra information on stderr.  (This may turn an abort into a segfault, of course)

Caveats:
- exact name of the API probably could be better
- I don't yet have a specific use for the "callback" idea; I was thinking of trying to display all objects that reference that object.  Might need a void* closure to be useful.  Might be a useless complication.
- Only tested on gcc-4.4.3 so far; the __STRING(expr) and __PRETTY_FUNCTION__ look non-portable.
- no test case; I thought about using ctypes to extract PyObject_IncRef from the implementation, but this is likely to lead to brittle test cases.  Alternatively, is xxmodule to be used for this kind of thing?

Thoughts?
History
Date User Action Args
2010-07-14 23:50:51dmalcolmsetrecipients: + dmalcolm
2010-07-14 23:50:50dmalcolmsetmessageid: <1279151450.93.0.973335817084.issue9263@psf.upfronthosting.co.za>
2010-07-14 23:50:49dmalcolmlinkissue9263 messages
2010-07-14 23:50:47dmalcolmcreate