Comment 19 for bug 571093

I've had another look at this bug, reproducing etc, this time through GDB, with the output from valgrind & the debug output in my last two posts, here is what I believe is happening:

1. multipath -v4 gets called (or other appropriate trigger)
 - multipath detects a device that it believes is new, which triggers a udev add/change event
2. libvirt picks up on the events and runs the code within udevAddOneDevice(device)
3. While running around it seems that one of the if functions around node_device_udev.c:1230 returns non zero and hits the 'goto out' call.
4. As a result virNodeDeviceDefFree(def); does not get called and libvirt still thinks that the device exists.
5. When multipath realizes itself that the device isn't worth anything it triggers a udev remove call.
6. libvirt tries to remove the device but fails early on because it doesn't know what udev is talking about, and again doesn't free memory.

For what it's worth, just before the goto out call was made gdb was about to tell me the following:
(gdb) p def
$4 = (virNodeDeviceDefPtr) 0x1cabd70
(gdb) x/t def
0x1cabd70: 00000000000000000000000000000000
(gdb) x/3x def
0x1cabd70: 0x00000000 0x00000000 0x00000000
(gdb) x/s def
0x1cabd70: ""

I've got a distinct feeling that if virNodeDeviceDefFree(def) was called before the function returned, this memory leak wouldn't have happened.

I'm going to give it a test and see what happens.