Re: [libodbcxx-devel] segmentation fault help please

[Simon W. <si...@gi...>]

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