I'm seeing ConnOpener leaks in 3.2.5. I compiled with --enable-debug-cbdata and cachemgr reports most of the CommOpener objects as invalid, each with a lock count greater than 0. The lines look like: Pointer Type Locks Allocated by !0x20959018 29 2 comm/ConnOpener.h:74 !0x1efba998 29 2 comm/ConnOpener.h:74 !0x21bd4248 29 1 ../../src/comm/ConnOpener.h:74
After 100,000 queries I have 2,000 CommOpener objects allocated with 1,900 in use. Of those, 1850 are invalid. Could someone that understands cbdata take a look? As near as I can tell only Comm::ConnOpener::InProgresConnectRetry() and Comm::ConnOpener::DelayedConnectRetry() duplicate the CommOpener object (by calling ptr->valid()). It looks like the original is destructed, but I'm not sure if that is correct. cbdataInternalFree() will decrement the lock count, but before it does it first checks and clears the "valid" flag. If the "valid" flag is not set, cbdataInternalFree asserts. If it is set, it clears the "valid" flag and then decrements the lock count. I'm very confused about the way cbdata is working. I'm guessing that the "valid" flag is getting cleared before all the locks are removed, which will prevent any more locks from being removed. The twisty maze of function templates is too much for me. Could someone please take a look? Mike Mitchell
