This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients bkabrda, dmalcolm, loewis, ncoghlan, pitrou, serhiy.storchaka, vstinner
Date 2018-10-26.17:13:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1540574031.22.0.788709270274.issue9263@psf.upfronthosting.co.za>
In-reply-to
Content
I pushed the change and even more, so I consider that the issue can now be closed... 8 years later! Thank you very much Dave Malcolm for this nice idea, and for its implementation. Thanks Bohuslav "Slavek" Kabrda for the rebase in 2013, and thanks to my colleagues who rebased the patch frequently since 2013 in the Fedora package!

Maybe some people (like me?) want to use _PyObject_ASSERT() in more places, but I consider that we don't need to leave this issue open just for that.


I took the 00170-gc-assertions.patch rebased on Python 3.7.1 by my colleagues for the Fedora package, and I rebased it on master. I modified more functions in object.c and typeobject.c to use _PyObject_ASSERT(). I tried to not replace all assert(), but only when it's revelant.

I added code to detect if the object memory has been freed to avoid derefering 0xdbdbdbdbdbdbdbdb pointers which is very likely to cause a segmantation fault. It should reduce the risk of crash when dumping the faulty object.


Dave Malcolm:
> - Only tested on gcc-4.4.3 so far; the __STRING(expr) and __PRETTY_FUNCTION__ look non-portable.

I used Py_STRINGIFY() and __func__ in the final patch. __func__ is part of the C99 standard which is now required since Python 3.6: see PEP 7.


Dave Malcolm:
> - 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?

I reworked the unit test to not use ctypes, but write the crashing code in C instead.


Antoine Pitrou:
> How about turning these asserts into Py_FatalError()s and then enabling Victor's faulthandler extension?

Done.
History
Date User Action Args
2018-10-26 17:13:51vstinnersetrecipients: + vstinner, loewis, ncoghlan, pitrou, dmalcolm, serhiy.storchaka, bkabrda
2018-10-26 17:13:51vstinnersetmessageid: <1540574031.22.0.788709270274.issue9263@psf.upfronthosting.co.za>
2018-10-26 17:13:51vstinnerlinkissue9263 messages
2018-10-26 17:13:51vstinnercreate