Skip to content

Memory leaks in BTreeMap with allocator_api enabled #106203

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

Open
fuyufjh opened this issue Dec 28, 2022 · 1 comment
Open

Memory leaks in BTreeMap with allocator_api enabled #106203

fuyufjh opened this issue Dec 28, 2022 · 1 comment
Labels
A-allocators Area: Custom and system allocators C-bug Category: This is a bug. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@fuyufjh
Copy link

fuyufjh commented Dec 28, 2022

I tried this code:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=23d67c52988b3be4eb1ddb6373da124d

fn main() {
    let allocator = AllocWrapper(Arc::new(std::alloc::System));

    println!("count = {}", Arc::strong_count(&allocator.0));
    let mut btree_map: BTreeMap<i32, i32, _> = BTreeMap::new_in(allocator.clone());
    println!("count = {}", Arc::strong_count(&allocator.0));
    btree_map.insert(1, 1);
    println!("count = {}", Arc::strong_count(&allocator.0));
    drop(btree_map);
    println!("count = {}", Arc::strong_count(&allocator.0)); // expect 1 got 2!
}

I expected to see this happen:

The reference count of the Arc should reduce to 1, so that it can be released correctly.

Instead, this happened:

The reference count of the Arc remains 2, so it will never be released.

Meta

Build using the Nightly version: 1.68.0-nightly

(2022-12-26 88c58e3c2c097ebffac4)

with

#![feature(btreemap_alloc)]
#![feature(allocator_api)]
@fuyufjh fuyufjh added the C-bug Category: This is a bug. label Dec 28, 2022
@ChrisDenton ChrisDenton added A-allocators Area: Custom and system allocators T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 22, 2023
@TDecking
Copy link
Contributor

The leak happens in NodeRef::from_new_leaf, which calls Box::leak. NodeRef::from_new_internal also has the same issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-allocators Area: Custom and system allocators C-bug Category: This is a bug. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants