From cf83148e04f6b081ff548a3a5ff98b7182d0878d Mon Sep 17 00:00:00 2001 From: Matthew Fernandez Date: Tue, 5 Apr 2022 19:38:18 -0700 Subject: [PATCH] Poppler plugin gvloadimage_poppler_load: fix: match Glib allocation and free MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit The variable `absolute` is allocated using Glib’s `g_strdup` and friends. Quoting the Glib docs:¹ It's important to match `g_malloc()` (and wrappers such as `g_new()`) with `g_free()`, `g_slice_alloc()` (and wrappers such as `g_slice_new()`) with `g_slice_free()`, plain `malloc()` with `free()`, and (if you're using C++) `new` with `delete` and `new[]` with `delete[]`. Otherwise bad things can happen, since these allocators may use different memory pools (and new/delete call constructors and destructors). So a custom allocation scheme or arena can be in play. Basically if you `g_strdup` and then pair this with `free` (as was done in the code prior to this commit), you risk leaking memory from the Glib pool and corrupting your system allocator. Having said that, this is no longer a concern in newer Glib: Since GLib 2.46 `g_malloc()` is hardcoded to always use the system malloc implementation. Still, why tempt fate? ¹ https://developer-old.gnome.org/glib/stable/glib-Memory-Allocation.html --- plugin/poppler/gvloadimage_poppler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugin/poppler/gvloadimage_poppler.c b/plugin/poppler/gvloadimage_poppler.c index 8e85fdbb5..185c1d970 100644 --- a/plugin/poppler/gvloadimage_poppler.c +++ b/plugin/poppler/gvloadimage_poppler.c @@ -69,7 +69,7 @@ static PopplerDocument* gvloadimage_poppler_load(GVJ_t * job, usershape_t *us) uri = g_filename_to_uri (absolute, NULL, &error); - free (absolute); + g_free(absolute); if (uri == NULL) { printf("%s\n", error->message); return NULL; -- 2.40.0