Okay, I've created a patch that should fix the issue in two ways, first as observed in my previous comment I suspected that adding a virNodeDeviceDefFree(def) to udevAddOneDevice() would solve the issue, it for the most part did but still left approximately an 8k RES memory leak.
Looking at the valgrind data that I had managed to generate (Comment #13) I suspected a second leak and noticed that udevProcessDeviceListEntry() after running udevAddOneDevice() ran udev_device_unref(device); which according to the udev code does:
* Drop a reference of a udev device. If the refcount reaches zero,
* the resources of the device will be released.
Based on the fact that the reference is wiped at the end of udevProcessDeviceListEntry() I have added it to udevEventHandleCallback() which is the other main location of udevAddOneDevice() getting called.
This is now resulting in no increase in RES memory (except for natural increases).
Okay, I've created a patch that should fix the issue in two ways, first as observed in my previous comment I suspected that adding a virNodeDeviceDe fFree(def) to udevAddOneDevice() would solve the issue, it for the most part did but still left approximately an 8k RES memory leak.
Looking at the valgrind data that I had managed to generate (Comment #13) I suspected a second leak and noticed that udevProcessDevi ceListEntry( ) after running udevAddOneDevice() ran udev_device_ unref(device) ; which according to the udev code does:
* Drop a reference of a udev device. If the refcount reaches zero,
* the resources of the device will be released.
Based on the fact that the reference is wiped at the end of udevProcessDevi ceListEntry( ) I have added it to udevEventHandle Callback( ) which is the other main location of udevAddOneDevice() getting called.
This is now resulting in no increase in RES memory (except for natural increases).
Patch is attached.