]> git.lizzy.rs Git - rust.git/commit
Auto merge of #24344 - gfxmonk:update-libbacktrace, r=pnkfelix
authorbors <bors@rust-lang.org>
Mon, 13 Apr 2015 10:23:58 +0000 (10:23 +0000)
committerbors <bors@rust-lang.org>
Mon, 13 Apr 2015 10:23:58 +0000 (10:23 +0000)
commit3cac76bcf239c5db7d612eea52dd39be6e0281b4
tree17d153d29074ac6fa4d23155bb6bb5858e39d89c
parent524547551cd6c9b33a9677e1a58e9a9d1e19c0fc
parent10073c23c67218a5e38f28e6859f3fd7785c6ae8
Auto merge of #24344 - gfxmonk:update-libbacktrace, r=pnkfelix

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:

 - cd8f31759fd04b9ce9c903fa00cae81dc5bba546
 - fcb30a0b67b1bd4acbc3422ff74fac5d031ae1ae

I have not reapplied f5765793b650e45e8c9bc89dfc7a4dc628123cb7 or d51047ded072b412ec18a6f78c1fb80835a477f5, 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.