-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Update libbacktrace #24344
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
Update libbacktrace #24344
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see CONTRIBUTING.md for more information. |
Fantastic! |
This should solve #24231. |
wow, skimming over this, seems like very little actually changed, apart from the aforementioned memory-usage fix, and the addition of a specialized sort routine. |
@bors r+ |
📌 Commit 10073c2 has been approved by |
⌛ Testing commit 10073c2 with merge 00c24ee... |
💔 Test failed - auto-mac-64-nopt-t |
I'm assuming the mac test failure above is just sporadic, as this component is only used on linux. |
@bors: retry yep, looks like. |
@gfxmonk libbacktrace isn't used only on Linux. The and under but yes, the mac test failure seems to be unrelated :) |
On linux, certain crashes can cause rust's backtrace generation code to consume huge amounts of memory (multiple gigabytes) when trying to generate a backtrace (e.g. servo/servo#5340). I tracked this down to a bug in libbacktrace's allocation strategy when processing large binaries, and thankfully it's already been fixed upstream. The change which fixes this specific issue is r210256, and is discussed here: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00547.html I assume we'd prefer to update libbacktrace wholesale, rather than cherry-picking individual patches, so this PR updates libbacktrace to the latest code from svn://gcc.gnu.org/svn/gcc/trunk/libbacktrace (r220112). I've copied the upstream code and reapplied the parts of the following commits which touch src/libbacktrace: - cd8f317 - fcb30a0 I have not reapplied f576579 or d51047d, as those are both cosmetic cleanups applied to the entire codebase. For this directory, it seems worthwhile diverging as little as possible from upstream, to reduce the effort of future updates. But I can add them as well if preferred.
On linux, certain crashes can cause rust's backtrace generation code to consume huge amounts of memory (multiple gigabytes) when trying to generate a backtrace (e.g. servo/servo#5340).
I tracked this down to a bug in libbacktrace's allocation strategy when processing large binaries, and thankfully it's already been fixed upstream.
The change which fixes this specific issue is r210256, and is discussed here:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00547.html
I assume we'd prefer to update libbacktrace wholesale, rather than cherry-picking individual patches, so this PR updates libbacktrace to the latest code from svn://gcc.gnu.org/svn/gcc/trunk/libbacktrace (r220112).
I've copied the upstream code and reapplied the parts of the following commits which touch src/libbacktrace:
I have not reapplied f576579 or d51047d, as those are both cosmetic cleanups applied to the entire codebase. For this directory, it seems worthwhile diverging as little as possible from upstream, to reduce the effort of future updates. But I can add them as well if preferred.