<div dir="ltr"><div><div><div>Hey,<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 14, 2016 at 1:01 PM, Caolán McNamara <span dir="ltr"><<a href="mailto:caolanm@redhat.com" target="_blank">caolanm@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Sat, 2016-03-12 at 17:28 +0100, Markus Mohrhard wrote:<br>
> Hey,<br>
><br>
> so while looking through the calc memory leaks I have many leaks<br>
> related to the return object of Application::PostUserEvent. The<br>
> returned value is created with new but I see no clear ownership for<br>
> the returned value.<br>
><br>
> Does anyone known who should actually own that object? It seems to be<br>
> passed around a lot and there is the RemoveUserEvent function but I<br>
> did not see any code that actually deletes the object.<br>
<br>
</span>The ImplSVEvent goes into the various platform event queues. When all<br>
goes well it eventually gets dispatched back into the platform<br>
independent code and ends up in ImplHandleUserEvent where it gets<br>
deleted.<br>
<br>
The SalGenericDisplay will delete ImplSVEvents which *didn't* get<br>
dispatched in SalGenericDisplay::deregisterFrame.<br>
<br>
So presumably your leak doesn't hit either getting dispatched and thus<br>
deleted, or detected during some teardown case as an undispatched event<br>
and deleted by the platform-dependent event queue handler.<br>
<span><font color="#888888"><br>
C.<br></font></span></blockquote></div></div><br></div>Thanks a lot. That helped me track down the memory leak in the headless backend. See <a href="https://gerrit.libreoffice.org/23248">https://gerrit.libreoffice.org/23248</a>. Review highly appreciated.<br><br></div>Regards,<br></div>Markus<br></div>