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 larry
Recipients davin, larry, serhiy.storchaka, skrah, vstinner, xdegaye
Date 2017-10-31.19:32:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1509478329.84.0.213398074469.issue31626@psf.upfronthosting.co.za>
In-reply-to
Content
> Most, if not all, calls to _PyMem_DebugRawRealloc() are protected by
> the GIL. If there is a single thread using the memory block,
> I think that it's perfectly fine to write after it's deallocated.

I don't quite follow where the write-after-free is happening, but: C's free() function is *not* protected by the GIL.  So if you're running in a multithreaded program where other threads aren't blocked by the GIL, one of these other threads could very easily allocate this freshly-freed memory.  And if you wrote to it after the memory was allocated to this other thread, congrats, your program is no longer correct.
History
Date User Action Args
2017-10-31 19:32:09larrysetrecipients: + larry, vstinner, skrah, xdegaye, serhiy.storchaka, davin
2017-10-31 19:32:09larrysetmessageid: <1509478329.84.0.213398074469.issue31626@psf.upfronthosting.co.za>
2017-10-31 19:32:09larrylinkissue31626 messages
2017-10-31 19:32:09larrycreate