On 5/18/26 4:15 AM, Martin Kletzander via Devel wrote:
On Fri, May 15, 2026 at 03:06:26PM -0400, Laine Stump wrote:
On 5/14/26 9:56 AM, Martin Kletzander via Devel wrote:
From: Martin Kletzander <[email protected]>
I did not check whether the issue started at this point, it might have
been that the double-free happened way layer after some other changes,
it's just that this particular commit was ideal to revert.
Since I felt responsible, I did check, and it looks like there was
immediately an issue as soon as I made that change. So yeah, it was all
me :-/.
(Some of the changes didn't need to be reverted (those g_free()ing
memory pointed to by a member of an object that is itself being
g_free()ed (or now VIR_FREE()ed) in the immediately following code), but
on the other hand after seeing this disastrous effect of a "simple
cleanup", maybe *all* g_free()s should just be changed to VIR_FREE()
anyway - it's currently evenly balanced between g_free() and VIR_FREE()
(just under 2000 occurrences each (with about 450 uses of
g_clear_pointer combined with a *Free() function or g_free() itself).
They are not needed, but it reads better when they are not mixed, and
this is not a code that would run each 10ms or something. Not to
mention the latency of vmware soap api. But if you feel like changing
it so that anything under *p is just g_free()'d and *p VIR_FREE()'d, I'd
be completely fine with that.
Definitely keep it the way you have it. My prose was a bit obtuse, but
I'm almost totally serious about replacing *all* g_free() *everywhere*
with VIR_FREE() just for consistency and the tiny chance that it could
eliminate (or at least expose) more as-yet-unseen use-after-free cases.
