On 09/17/2012 05:50 PM, Eric Blake wrote:
On 09/17/2012 03:48 AM, Laine Stump wrote:
virNetworkAssignDef was allocating a new network object, initing and grabbing its lock, then potentially freeing it without unlocking or destroying the lock. In practice 1) this will probably never happen, and 2) even if it did, the lock implementation used on most (all?) This is probably a safe claim for Unix-like systems, but mingw can be rather surprising, and I think actually leaks resources in this scenario.
Yeah, I can easily imagine that, which is why it bothered me.
platforms doesn't actually hold any resources for an initialized or held lock, but it still bothered me, so I moved the realloc that could lead to this bad situation earlier in the function, and now the mutex isn't inited or locked until we are assured of complete success. --- src/conf/network_conf.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) ACK.
This also doesn't need the rest of the series, so I'll push now to avoid the rush. Thanks!