From: Simon W. <si...@gi...> - 2012-06-07 01:09:34
|
On 06/06/2012 07:27 PM, Pete wrote: > > Further to Jan's suggestions, unless you do: > > odbc::DriverManager::shutdown(); > > before exiting from your program you'll get leaks. > Thanks for that Pete and Jan. I got this error upon exit: error code: 0 error message: Failed to shutdown DriverManager: [unixODBC][Driver Manager]Function sequence error As I'd gone back to using unique_ptr, I figured I should reset() them in the order Jan specified - which makes sense. But there is still a memory leak. Is this to be expected? Am I looking at something to do with the ODBC libs? $ valgrind --tool=memcheck --leak-check=full ./testODBCtds ==14771== Memcheck, a memory error detector ==14771== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==14771== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==14771== Command: ./testODBCtds ==14771== 1 ==14771== ==14771== HEAP SUMMARY: ==14771== in use at exit: 5,192 bytes in 201 blocks ==14771== total heap usage: 1,788 allocs, 1,587 frees, 1,455,615 bytes allocated ==14771== ==14771== 160 (40 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 192 of 195 ==14771== at 0x4023F50: malloc (vg_replace_malloc.c:236) ==14771== by 0x429C1E3: nss_parse_service_list (nsswitch.c:622) ==14771== by 0x429C926: __nss_database_lookup (nsswitch.c:164) ==14771== by 0x402AEAB: ??? ==14771== by 0x402BB6C: ??? ==14771== by 0x4255994: getpwuid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253) ==14771== by 0x42552FE: getpwuid (getXXbyYY.c:117) ==14771== by 0x4378920: ??? (in /usr/lib/libodbc.so.1.0.0) ==14771== by 0x4375445: ??? (in /usr/lib/libodbc.so.1.0.0) ==14771== by 0x43617FF: ??? (in /usr/lib/libodbc.so.1.0.0) ==14771== by 0x43330E2: SQLDriverConnect (in /usr/lib/libodbc.so.1.0.0) ==14771== by 0x40493FE: odbc::Connection::_connect(std::string const&, unsigned short) (connection.cpp:227) ==14771== ==14771== LEAK SUMMARY: ==14771== definitely lost: 40 bytes in 1 blocks ==14771== indirectly lost: 120 bytes in 10 blocks ==14771== possibly lost: 0 bytes in 0 blocks ==14771== still reachable: 5,032 bytes in 190 blocks ==14771== suppressed: 0 bytes in 0 blocks ==14771== Reachable blocks (those to which a pointer was found) are not shown. ==14771== To see them, rerun with: --leak-check=full --show-reachable=yes ==14771== ==14771== For counts of detected and suppressed errors, rerun with: -v ==14771== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 45 from 10) code: #include <string> #include <sstream> #include <iostream> #include <memory> #include <odbc++/drivermanager.h> #include <odbc++/connection.h> #include <odbc++/preparedstatement.h> #include <odbc++/callablestatement.h> #include <odbc++/resultset.h> #include <odbc++/databasemetadata.h> #include <odbc++/resultsetmetadata.h> int main(int argc, char** argv) { int test; std::string dbConnectString = "DSN=htms02;UID=cms;PWD=cms1"; std::stringstream query; query << "select 1 as test"; try { std::unique_ptr<odbc::Connection> connection (odbc::DriverManager::getConnection(dbConnectString)); std::unique_ptr<odbc::Statement> statement (connection->createStatement()); std::unique_ptr<odbc::ResultSet> resultSet (statement->executeQuery(query.str())); while (resultSet->next()) { test = resultSet->getInt("test"); } std::cout << test << std::endl; resultSet.reset(); statement.reset(); connection.reset(); odbc::DriverManager::shutdown(); } catch(odbc::SQLException& e) { std::cout << std::endl << "error code: "<< e.getErrorCode() << std::endl << "error message: " << e.getMessage() << std::endl; } return 0; } -- simonsmicrophone.com |