-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-44184: Fix subtype_dealloc() for freed type #26274
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fix makes no sense to me, if what you say in the comment was actually the root cause, we would be seeing this under vallgrind or the address sanitizer and I could not reproduce it
When you're done making the requested changes, leave the comment: |
I was able to reproduce the crash under ASAN: https://bugs.python.org/msg394085
This is enough to crash it:
can we maybe add a test based on this? |
I would prefer to not rely directly on os.register_at_fork() to ensure that the object will survive until the last GC collection. I would prefer an abstraction function in the test.support module. I will try to add a test. |
I can reproduce the bug on macOS using the address sanitiser. The patch also fixes the buildbot problems on #24203 (comment) |
Fix a crash at Python exit when a deallocator function removes the last strong reference to a heap type. Don't read type memory after calling basedealloc() since basedealloc() can deallocate the type and free its memory.
@pablogsal: I added an unit test, would you mind to review the updated PR? I was too lazy to add an abstraction. Since the test is in test_gc, IMO it's ok. First, I wanted to add the test to test_ast. |
Ah, register_at_fork() is not available on Windows. I modified my test to use codecs.register() instead. You can test manually that the unit test fails as expected with this change:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10. |
GH-26290 is a backport of this pull request to the 3.10 branch. |
Fix a crash at Python exit when a deallocator function removes the last strong reference to a heap type. Don't read type memory after calling basedealloc() since basedealloc() can deallocate the type and free its memory. _PyMem_IsPtrFreed() argument is now constant. (cherry picked from commit 615069e) Co-authored-by: Victor Stinner <vstinner@python.org>
Thanks for reviews @pablogsal and @erlend-aasland! |
Fix a crash at Python exit when a deallocator function removes the last strong reference to a heap type. Don't read type memory after calling basedealloc() since basedealloc() can deallocate the type and free its memory. _PyMem_IsPtrFreed() argument is now constant. (cherry picked from commit 615069e) Co-authored-by: Victor Stinner <vstinner@python.org> Co-authored-by: Victor Stinner <vstinner@python.org>
… it is also trying to use a type after it's potentially been freed.
GH-27165) The non-GC-type branch of subtype_dealloc is using the type of an object after freeing in the same unsafe way as GH-26274 fixes. (I believe the old news entry covers this change well enough.) https://bugs.python.org/issue44184
…dealloc (pythonGH-27165) The non-GC-type branch of subtype_dealloc is using the type of an object after freeing in the same unsafe way as pythonGH-26274 fixes. (I believe the old news entry covers this change well enough.) https://bugs.python.org/issue44184 (cherry picked from commit 074e765) Co-authored-by: T. Wouters <thomas@python.org>
…dealloc (pythonGH-27165) The non-GC-type branch of subtype_dealloc is using the type of an object after freeing in the same unsafe way as pythonGH-26274 fixes. (I believe the old news entry covers this change well enough.) https://bugs.python.org/issue44184 (cherry picked from commit 074e765) Co-authored-by: T. Wouters <thomas@python.org>
Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9. |
Fix a crash at Python exit when a deallocator function removes the last strong reference to a heap type. Don't read type memory after calling basedealloc() since basedealloc() can deallocate the type and free its memory. _PyMem_IsPtrFreed() argument is now constant. (cherry picked from commit 615069e) Co-authored-by: Victor Stinner <vstinner@python.org>
GH-27176 is a backport of this pull request to the 3.9 branch. |
GH-27165) (GH-27174) The non-GC-type branch of subtype_dealloc is using the type of an object after freeing in the same unsafe way as GH-26274 fixes. (I believe the old news entry covers this change well enough.) https://bugs.python.org/issue44184 (cherry picked from commit 074e765) Co-authored-by: T. Wouters <thomas@python.org>
GH-27165) (GH-27175) The non-GC-type branch of subtype_dealloc is using the type of an object after freeing in the same unsafe way as GH-26274 fixes. (I believe the old news entry covers this change well enough.) https://bugs.python.org/issue44184 (cherry picked from commit 074e765) Co-authored-by: T. Wouters <thomas@python.org>
Fix a crash at Python exit when a deallocator function removes the last strong reference to a heap type. Don't read type memory after calling basedealloc() since basedealloc() can deallocate the type and free its memory. _PyMem_IsPtrFreed() argument is now constant. (cherry picked from commit 615069e) Co-authored-by: Victor Stinner <vstinner@python.org>
For posterity: bpo-42961 reports the same issue and has a nice reproducer. |
Fix a crash at Python exit when a deallocator function removes the
last strong reference to a heap type.
Don't read type memory after calling basedealloc() since
basedealloc() can deallocate the type and free its memory.
https://bugs.python.org/issue44184