[issue38379] finalizer resurrection in gc

Change by Eryk Sun : -- Removed message: https://bugs.python.org/msg405696 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38379] finalizer resurrection in gc

Change by Eryk Sun : -- components: +Interpreter Core -IDLE nosy: -ahmedsayeed1982, terry.reedy versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6 ___ Python tracker

[issue38379] finalizer resurrection in gc

Ahmed Sayeed added the comment: If you create a new TUI layout, don't include the status window, and then change from a layout with the status window to the new one, gdb crashes. http://www.compilatori.com/category/tech/ (gdb) layout src (gdb) tui new-layout test src 2 cmd 1

[issue38379] finalizer resurrection in gc

Lewis Gaul added the comment: You're right that's how I had interpreted it, thanks for clarifying. I was wondering if this could be related to an issue I've hit with gc.collect() getting slower and slower in a test suite, but that now seems unlikely, so I won't go into that here.

[issue38379] finalizer resurrection in gc

Tim Peters added the comment: I suspect you're reading some specific technical meaning into the word "block" that the PR and release note didn't intend by their informal use of the word. But I'm unclear on what technical meaning you have in mind. Before the change, gc "just gave up" after

[issue38379] finalizer resurrection in gc

Lewis Gaul added the comment: I noticed this bug is mentioned in the 3.9 release notes with a note similar to the title of the 4th PR: "garbage collection does not block on resurrected objects". I can't see any mention of a blocking issue here on the issue: > The bug: the stats keep

[issue38379] finalizer resurrection in gc

Tim Peters added the comment: Everything here has been addressed, so closing this. zleak.py can apparently run forever now without leaking a byte :-) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python

[issue38379] finalizer resurrection in gc

Pablo Galindo Salgado added the comment: New changeset 466326dcdf038b948d94302c315be407c73e60d1 by Pablo Galindo in branch 'master': bpo-38379: Don't block collection of unreachable objects when some objects resurrect (GH-16687)

[issue38379] finalizer resurrection in gc

Change by Pablo Galindo Salgado : -- pull_requests: +16273 pull_request: https://github.com/python/cpython/pull/16687 ___ Python tracker ___

[issue38379] finalizer resurrection in gc

miss-islington added the comment: New changeset a081e931505f190b5ccdff9a781e59b3f13fcc31 by Miss Islington (bot) (Pablo Galindo) in branch '3.7': [3.7] bpo-38379: don't claim objects are collected when they aren't (GH-16658) (GH-16685)

[issue38379] finalizer resurrection in gc

miss-islington added the comment: New changeset 0bd9fac7a866ec886ae8f93f9c24dcda6d436929 by Miss Islington (bot) (Pablo Galindo) in branch '3.8': [3.8] bpo-38379: don't claim objects are collected when they aren't (GH-16658) (GH-16683)

[issue38379] finalizer resurrection in gc

Pablo Galindo Salgado added the comment: Tim, I have created backports for 3.8 and 3.7 (PR 16683, PR 16685). In my case cherry_picker ecbf35f9335b0420cb8adfda6f299d6747a16515 3.7 and cherry_picker ecbf35f9335b0420cb8adfda6f299d6747a16515 3.8 works after fixing merge conflicts. Maybe there

[issue38379] finalizer resurrection in gc

Change by Pablo Galindo Salgado : -- pull_requests: +16271 pull_request: https://github.com/python/cpython/pull/16685 ___ Python tracker ___

[issue38379] finalizer resurrection in gc

Change by Pablo Galindo Salgado : -- pull_requests: +16269 stage: backport needed -> patch review pull_request: https://github.com/python/cpython/pull/16683 ___ Python tracker

[issue38379] finalizer resurrection in gc

Tim Peters added the comment: I checked the stat fix into master, but GH failed to backport to 3.7 or 3.8 and I'm clueless. More info in the PR. Does someone else here know how to get a backport done? -- stage: patch review -> backport needed versions: +Python 3.7, Python 3.8

[issue38379] finalizer resurrection in gc

Tim Peters added the comment: New changeset ecbf35f9335b0420cb8adfda6f299d6747a16515 by Tim Peters in branch 'master': bpo-38379: don't claim objects are collected when they aren't (#16658) https://github.com/python/cpython/commit/ecbf35f9335b0420cb8adfda6f299d6747a16515 --

[issue38379] finalizer resurrection in gc

Change by Pablo Galindo Salgado : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38379] finalizer resurrection in gc

Tim Peters added the comment: PR 16658 aims to repair the stats reported. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue38379] finalizer resurrection in gc

Change by Tim Peters : -- keywords: +patch pull_requests: +16241 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/16658 ___ Python tracker

[issue38379] finalizer resurrection in gc

Change by Joannah Nanjekye : -- nosy: +nanjekyejoannah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38379] finalizer resurrection in gc

Tim Peters added the comment: Just noting that check_garbage() currently only determines which trash objects are now directly reachable from outside. To be usable for the intended purpose, it would need to go on to compute which trash objects are reachable from those too. Maybe a new

[issue38379] finalizer resurrection in gc

New submission from Tim Peters : While people are thinking about gc, zleak.py shows a small bug, and a possible opportunity for improvement, in the way gc treats finalizers that resurrect objects. The bug: the stats keep claiming gc is collecting an enormous number of objects, but in fact