]> granicus.if.org Git - graphviz/commit
Poppler plugin gvloadimage_poppler_load: fix: match Glib allocation and free
authorMatthew Fernandez <matthew.fernandez@gmail.com>
Wed, 6 Apr 2022 02:38:18 +0000 (19:38 -0700)
committerMatthew Fernandez <matthew.fernandez@gmail.com>
Sat, 9 Apr 2022 18:20:30 +0000 (11:20 -0700)
commitcf83148e04f6b081ff548a3a5ff98b7182d0878d
tree591991db4d3ffedb0a7b5810684dd6c98dad4b0d
parent2774abe43e718bd4ccf9cd4df9e1052e2e021b9a
Poppler plugin gvloadimage_poppler_load: fix: match Glib allocation and free

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