-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Use of GC inside destructors aborts when destructor called from GC #6996
Comments
nominating for well-defined milestone |
This is still an issue. |
Accepted for milestone 1, well-defined |
Visiting for triage. Re-nominating. I think this should just be a "don't do this" in |
cc me |
there are a number of ways to handle this, e.g. not running user-defined destructors from within the GC coroutine (and instead deferring them to e.g. a guardian, or a concurrent finalization tasks). Not closing as not-a-bug, at least not yet, I want more time to investigate the design here. |
Nominating for closing, as this is a GC issue and GC is not in scope for 1.0. The corresponding TLS issue, #14807, is more important. |
Do we not allow for open bugs on feature-gated things? (Having said that, I would not object to taking this off the milestone, and in fact I will nominate it for that right now.) |
I think it would be reasonable to simply migrate the users of |
Updated comment/title to be relevant for today. |
Sorry, I meant nominating for removal from P-backcompat-lang. |
P-high, not 1.0 |
Gc is gone so closing. |
Allow missing panics doc if the panics occur only when debug-assertions is specified fixes rust-lang#6970 changelog: `missing_panics_doc`: Allow missing panics doc if the panics occur only when `debug-assertions` is specified.
Updated example
Original description
This program crashes:
With the current implementation, the crash message is:
But when we switch to tracing GC for @-pointers, I predict a new problem: the destructor won't run until an attempt to allocate another @-pointer fails, at which point @-pointers could no longer be allocatable... and the allocation would fail (even though the amount of live memory in use might be reasonably small). This raises some questions:
Related #910.
The text was updated successfully, but these errors were encountered: