-
Notifications
You must be signed in to change notification settings - Fork 50
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
Likely undefined behavior in PanickingAllocator #294
Comments
@jgallagher We really appreciate any comments! Especially for tricky code like this 😊 I had (incorrectly) thought that the |
Thank you for pointing this out! |
Sure thing; thanks for the gracious followup! :) FWIW in my case I ended up using fallible-collections and changing every call site that could allocate to use checked versions of methods, but it's not something I can really recommend: a) AFAIK there's no good way to make sure you caught all allocation points All in all a pretty unsatisfying solution. I'm anxiously awaiting |
The |
Waiting on upstream changes in rust |
The unstable flag was merged as mentioned above, it's released unstably as of |
Apologies for the out-of-the-blue random bug report, but I've been interested in Rust OOM behavior for a while and ran across #285. I believe this introduces undefined behavior per the docs of GlobalAlloc:
The last time I experimented with panicking allocators, the effect was that many (but not all!)
Drop
implementations did not run during the stack unwind. There is also a more general and pernicious issue that existing unsafe code (including potentially in the Rust std lib) is not exception safe across allocation attempts; even if relevant drops are run, such code may introduce memory unsafety if unwound.The text was updated successfully, but these errors were encountered: