On 04/13/2017 06:44 AM, Wang King wrote: While true this does "fix" this instance, it also doesn't seem to be the only instance [1] of this and isn't handled via "normal" error path using virObjectUnref(dom); [2] [1] example of another instance w/ similar code/leak/issue See also remoteRelayDomainEventJobCompleted I'll assume this one borrowed from remoteRelayDomainEventTunable considering which came first. [2] example of another instance w/ similar code, but no leak See also remoteDispatchConnectGetAllDomainStats FWIW: The sequence I used to search on is: make_nonnull_domain virTypedParamsSerialize While looking through the code during review, I noticed a couple of other possible cleanups. So, if you're feeling adventurous, there's also two instances where a VIR_STRDUP error is followed by a goto error where all the error label does is VIR_FREE the address that failed the VIR_STRDUP and there's no other way to get to the error label... See: remoteRelayDomainEventBlockJob2 remoteRelayDomainEventBlockJob It would seem those two could just have a return -1 instead to follow other similar such error paths: remoteRelayDomainEventDeviceRemovalFailed remoteRelayDomainEventDeviceAdded remoteRelayDomainEventDeviceRemoved remoteRelayDomainEventTrayChange John