https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68239
Bug ID: 68239
Summary: libbacktrace allocation is sometimes very slow
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: wtt6 at cornell dot edu
Target Milestone: ---
From https://github.com/rust-lang/rust/issues/29293
In the Rust project, we are encountering cases where libbacktrace spends about
a second performing the actual work of generating a backtrace and about a
minute managing its memory allocator (absolute times are machine-dependent,
obviously). The problem appears to be that the linked list of freed
allocations available for reuse ends up containing tens of thousands of entries
that are all too small to satisfy most (all?) allocation requests, and the
allocator loops over and tests all of them before deciding to mmap more memory.
