Skip to content
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

Consider using a drop guard when enabling tracking. #7

Open
tobz opened this issue Mar 10, 2022 · 0 comments
Open

Consider using a drop guard when enabling tracking. #7

tobz opened this issue Mar 10, 2022 · 0 comments

Comments

@tobz
Copy link
Owner

tobz commented Mar 10, 2022

In certain cases, leaving tracking enabled before main exits can lead to reentrancy of the tracking infrastructure as cleanup routines as triggered. As a concrete example, if println! is used in the allocation tracker implementation, this causes a panic at program exit:

  • implicit cleanup routine for stdio runs at end of main
  • this routine takes a lock and mutably borrows some internal state from a RefCell
  • a deallocation happens, which drops us into allocation tracking
  • as we println! in the allocation tracker, this drops us back into the print infrastructure
  • the locks guarding stdout/stderr are reentrant, so we still able to take them
  • the code again tries to mutably borrow some internal state, but alas, it is already borrowed
  • gasp! le panic.

While printing directly in the allocation tracker implementation is not advised, this still represents a general issue where we likely shouldn't be tracking anything past actual program code, which using a drop guard should achieve: we can clear the tracker implementation right before any runtime boilerplate cleanup runs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant