Shakthi Kannan writes:
 > The API has been changed in the latest source. So, I updated the
 > following code snippet, and I still see the memory leak:

Hi Shakthi,

I've reproduced the leak that you detected in the current cvs
sources. According to my analysis the drivers pass error messages
through dbd_geterror() as allocated
strings. _dbd_internal_error_handler() created another copy with
strdup() which isn't necessary. The latter copy was freed, the
original copy was left in place. I've fixed this leak in the current
cvs revision.

This is what I get now on my box when I run your test program:

==3717== HEAP SUMMARY:
==3717==     in use at exit: 161,359 bytes in 5,251 blocks
==3717==   total heap usage: 20,903 allocs, 15,652 frees, 16,739,701 bytes 
==3717== LEAK SUMMARY:
==3717==    definitely lost: 0 bytes in 0 blocks
==3717==    indirectly lost: 0 bytes in 0 blocks
==3717==      possibly lost: 0 bytes in 0 blocks
==3717==    still reachable: 157,263 bytes in 5,250 blocks
==3717==         suppressed: 4,096 bytes in 1 blocks
==3717== Reachable blocks (those to which a pointer was found) are not shown.
==3717== To see them, rerun with: --leak-check=full --show-reachable=yes
==3717== For counts of detected and suppressed errors, rerun with: -v
==3717== Use --track-origins=yes to see where uninitialised values come from
==3717== ERROR SUMMARY: 289 errors from 1 contexts (suppressed: 48 from 8)


Markus Hoenicka
AQ score 38

uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:
libdbi-users mailing list

Reply via email to