summaryrefslogtreecommitdiff
path: root/src/core
diff options
context:
space:
mode:
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2020-05-28 14:58:35 +0200
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2020-05-28 18:51:52 +0200
commit3fb2326f3ed87aa0b26078d307ebfb299e36286d (patch)
tree4cd4f128c538bcf701d141c402c39cb71d4a66c7 /src/core
parentdb868d45f9a50a63a03231e0f475baebd87dab82 (diff)
downloadsystemd-3fb2326f3ed87aa0b26078d307ebfb299e36286d.tar.gz
shared/unit-file: make sure the old hashmaps and sets are freed upon replacement
Possibly fixes #15220. (There might be another leak. I'm still investigating.) The leak would occur when the path cache was rebuilt. So in normal circumstances it wouldn't be too bad, since usually the path cache is not rebuilt too often. But the case in #15220, where new unit files are created in a loop and started, the leak occurs once for each unit file: $ for i in {1..300}; do cp ~/.config/systemd/user/test0001.service ~/.config/systemd/user/test$(printf %04d $i).service; systemctl --user start test$(printf %04d $i).service;done
Diffstat (limited to 'src/core')
-rw-r--r--src/core/manager.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/core/manager.c b/src/core/manager.c
index f15f845e81..7acbbb0b9e 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -696,7 +696,7 @@ static int manager_setup_prefix(Manager *m) {
static void manager_free_unit_name_maps(Manager *m) {
m->unit_id_map = hashmap_free(m->unit_id_map);
m->unit_name_map = hashmap_free(m->unit_name_map);
- m->unit_path_cache = set_free_free(m->unit_path_cache);
+ m->unit_path_cache = set_free(m->unit_path_cache);
m->unit_cache_mtime = 0;
}