mimo writes:
> closes a mysql connection - see below. Running this through valgrind's
> memory
> checker gives a leak report for dbi_conn_connect (output attached further
> down).
I've tried to reproduce this problem on my FreeBSD box, to no avail
yet. First of all, being a C programmer I failed to compile your test
successfully. Could you please post the magic gcc incantation which
will compile the program? Second, FreeBSD 7.2 seems to have problems
unloading the drivers while runing under gdb. I needed to check the
program in gdb as valgrind would cause the program to dump core. In
any case, even switching off the code which would unload the driver
when shutting down the library wouldn't make valgrind happy. A quick
search on the web confirmed that valgrind is not fully operational on
FreeBSD currently. I'll try again tomorrow on a Debian box.
> Any help would be greatly appreciated - btw my server (using 0.8.2) is multi-
> threaded - I've seen previous posts here about libdbi and thread safety -
> and
> I can confirm it's working fine if you take a couple of precautions. Let me
> know
> if you want more detailed instructions..
>
Yes, please.
regards,
Markus
> Thanks,
>
> mimo
>
> <code>
> #include <stdio.h>
> #include <stdlib.h>
> #include <mysql/mysql.h>
> #include <string>
> #include <iostream>
> #include <dbi/dbi.h>
>
> using namespace std;
>
> int main() {
> dbi_initialize(0);
> dbi_conn con = dbi_conn_new("mysql");
> dbi_conn_set_option(con, "username", "root");
> dbi_conn_set_option(con, "dbname", "greylist");
> if (dbi_conn_connect(con) != 0) {
> cerr << "dbi_conn_connect() failed" << endl;
> }
>
> dbi_conn_close(con);
> dbi_shutdown();
> return 0;
> }
> </code>
>
> valgrind --leak-check=full --show-reachable=yes --track-origins=yes
> ./dbi_mysql
>
> ==6633== Memcheck, a memory error detector.
>
> ==6633== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
>
> ==6633== Using LibVEX rev 1884, a library for dynamic binary translation.
>
> ==6633== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
>
> ==6633== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation
> framework.
>
> ==6633== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
>
> ==6633== For more details, rerun with: -v
>
> ==6633==
>
> ==6633==
>
> ==6633== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 2)
>
> ==6633== malloc/free: in use at exit: 61,376 bytes in 17 blocks.
>
> ==6633== malloc/free: 110 allocs, 93 frees, 122,903 bytes allocated.
>
> ==6633== For counts of detected errors, rerun with: -v
>
> ==6633== searching for pointers to 17 not-freed blocks.
>
> ==6633== checked 204,304 bytes.
>
> ==6633==
>
> ==6633== 24 bytes in 1 blocks are definitely lost in loss record 1 of 4
>
> ==6633== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
>
> ==6633== by 0x65F2B51: ???
>
> ==6633== by 0x65F387A: ???
>
> ==6633== by 0x65F1049: ???
>
> ==6633== by 0x661810E: ???
>
> ==6633== by 0x639B3B9: ???
>
> ==6633== by 0x4E30AF4: dbi_conn_connect (in /usr/lib/libdbi.so.0.0.5)
>
> ==6633== by 0x400DDC: main (dbi_mysql.cpp:17)
>
> ==6633==
>
> ==6633==
>
> ==6633== 32 bytes in 1 blocks are still reachable in loss record 2 of 4
>
> ==6633== at 0x4C25684: calloc (vg_replace_malloc.c:397)
>
> ==6633== by 0x5D9433F: _dlerror_run (dlerror.c:142)
>
> ==6633== by 0x5D93EC0: dlopen@@GLIBC_2.2.5 (dlopen.c:88)
>
> ==6633== by 0x4E31C08: dbi_initialize (in /usr/lib/libdbi.so.0.0.5)
>
> ==6633== by 0x400D9F: main (dbi_mysql.cpp:13)
>
> ==6633==
>
> ==6633==
>
> ==6633== 61,320 (4,088 direct, 57,232 indirect) bytes in 1 blocks are
> definitely lost in loss record 3 of 4
>
> ==6633== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
>
> ==6633== by 0x65F9B85: ???
>
> ==6633== by 0x65FA26F: ???
>
> ==6633== by 0x65FAC64: ???
>
> ==6633== by 0x65FAE56: ???
>
> ==6633== by 0x6617ED9: ???
>
> ==6633== by 0x6619E57: ???
>
> ==6633== by 0x639B3EE: ???
>
> ==6633== by 0x4E30AF4: dbi_conn_connect (in /usr/lib/libdbi.so.0.0.5)
> ==6633== by 0x400DDC: main (dbi_mysql.cpp:17)
> ==6633==
> ==6633==
> ==6633== 57,232 bytes in 14 blocks are indirectly lost in loss record 4 of 4
> ==6633== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
> ==6633== by 0x65F9B85: ???
> ==6633== by 0x65FA28B: ???
> ==6633== by 0x65FAC64: ???
> ==6633== by 0x65FAE56: ???
> ==6633== by 0x6617ED9: ???
> ==6633== by 0x6619E57: ???
> ==6633== by 0x639B3EE: ???
> ==6633== by 0x4E30AF4: dbi_conn_connect (in /usr/lib/libdbi.so.0.0.5)
> ==6633== by 0x400DDC: main (dbi_mysql.cpp:17)
> ==6633==
> ==6633== LEAK SUMMARY:
> ==6633== definitely lost: 4,112 bytes in 2 blocks.
> ==6633== indirectly lost: 57,232 bytes in 14 blocks.
> ==6633== possibly lost: 0 bytes in 0 blocks.
> ==6633== still reachable: 32 bytes in 1 blocks.
> ==6633== suppressed: 0 bytes in 0 blocks.
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> libdbi-devel mailing list
> libdbi-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libdbi-devel
--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
libdbi-devel mailing list
libdbi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-devel
