Fix memory leak when LeapMap is dropped after a resize (issue #16)#21
Open
mandrean wants to merge 1 commit intorobclu:mainfrom
Open
Fix memory leak when LeapMap is dropped after a resize (issue #16)#21mandrean wants to merge 1 commit intorobclu:mainfrom
mandrean wants to merge 1 commit intorobclu:mainfrom
Conversation
Two bugs caused memory to leak after each create-insert-drop cycle that triggered a migration (resize): 1. Source tables never freed on drop: After a successful migration the old source table is stored in `migrator.sources` and is only moved to `migrator.stale_sources` during the *next* call to `initialize_migrator`. If the map is dropped before a second migration the source tables are never freed, accounting for the ~218 MB per-round leak reported in the issue. Fix: iterate `migrator.sources` in `Drop` and explicitly free each source table's buckets and struct, mirroring what `cleanup_stale_table` does for entries in `stale_sources`. 2. Migrator Vec fields leaked via missing drop_in_place: `Migrator` contains `sources: Vec<MigrationSource<K,V>>` and `stale_sources: Vec<AtomicPtr<Table<K,V>>>`. The previous code called `deallocate` on the raw Migrator memory without first calling `drop_in_place`, so those Vecs' backing heap buffers were never freed. Fix: call `std::ptr::drop_in_place(migrator_ptr)` immediately before `deallocate` so that the Vec destructors run correctly. A regression test using a custom counting allocator is added to `leapmap.rs` that asserts zero bytes remain allocated after the map is dropped following a resize.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two bugs in the
Dropimpl caused memory to leak on every create-insert-drop cycle that triggered a resize:After a successful migration the old source table stays in
migrator.sourcesand is only moved tomigrator.stale_sourceson the nextinitialize_migratorcall. If the map is dropped before a second resize those tables are never freed (~218 MB per cycle as reported in the issue). Fix: iteratemigrator.sourcesinDropand free each source table, mirroring whatcleanup_stale_tabledoes forstale_sources.Migratorownssources: Vec<...>andstale_sources: Vec<...>. The previous code calleddeallocateon the raw struct bytes without first callingdrop_in_place, so the Vec backing buffers were never freed. Fix: callstd::ptr::drop_in_place(migrator_ptr)beforedeallocate.Both fixes are in
Droponly. The hot path (insert, get, remove, resize) is unchanged, so there is no performance regression.A regression test using a custom counting allocator verifies this directly:
Closes #16.