|
From: Pete <pe...@ka...> - 2012-06-06 10:45:10
|
Further to Jan's suggestions, unless you do:
odbc::DriverManager::shutdown();
before exiting from your program you'll get leaks.
Pete
> -----Original Message-----
> From: Simon Walter [mailto:si...@gi...]
> Sent: Wednesday, 6 June 2012 5:45 p.m.
> To: lib...@li...
> Subject: [libodbcxx-devel] segmentation fault help please
>
> Hi,
>
> I have here a very simple test program that crashes with a
> SIGSEGV. When running it through valgrind, it shows memory leaks.
>
> I've written this piece of code as I am having trouble with a
> larger project. However, I think I've isolated it to
> libodbc++ or unixodbc.
>
> I initially used std::unique_ptr. But thought I'd try plain
> old pointers for this test. Either way, there are probelms.
>
> Here is the program:
> ---------------------------------------
> #include <string>
> #include <sstream>
> #include <iostream>
> #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=agentportal;USER=xxx;PASSWORD=xxx";
> std::stringstream query;
> query << "select sleep(" << 30 << "), 1 as test";
>
> try
> {
> odbc::Connection* connection =
> odbc::DriverManager::getConnection(dbConnectString);
> odbc::Statement* statement = connection->createStatement();
> odbc::ResultSet* resultSet =
> statement->executeQuery(query.str());
>
> while (resultSet->next())
> {
> test = resultSet->getInt("test");
> }
>
> delete connection;
> delete statement;
> delete resultSet;
> }
> catch(odbc::SQLException& e)
> {
> std::cout << std::endl << "error code: "<<
> e.getErrorCode() << std::endl << "error message: " <<
> e.getMessage() << std::endl;
> }
>
> return 0;
> }
> ---------------------------------------
> #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=agentportal;USER=xxx;PASSWORD=xxx";
> 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;
> }
> catch(odbc::SQLException& e)
> {
> std::cout << std::endl << "error code: "<<
> e.getErrorCode() << std::endl << "error message: " <<
> e.getMessage() << std::endl;
> }
>
> return 0;
> }
> ---------------------------------------
> (gdb) r
> Starting program: /home/weelz/htserve/trunk/testODBC
> [Thread debugging using libthread_db enabled] [New Thread
> 0xb799cb70 (LWP 7865)] [Thread 0xb799cb70 (LWP 7865) exited]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000489 in ?? ()
> (gdb) bt
> #0 0x00000489 in ?? ()
> #1 0xb7d18ca6 in __libc_start_main (main=0x8048e64 <main>,
> argc=1, ubp_av=0xbffff7a4, init=0x8049230 <__libc_csu_init>,
> fini=0x8049220 <__libc_csu_fini>, rtld_fini=0xb7ff1380
> <_dl_fini>, stack_end=0xbffff79c)
> at libc-start.c:228
> #2 0x08048dd1 in _start ()
> (gdb)
> ---------------------------------------
> I've attached the valgrind output as it is rather long.
> prt.log is for the plain pointer version up top. unique.log
> is for the version that uses unique_ptr. Admittedly, the
> unique_ptr behaves better, but still has issues.
>
> I suspect I am doing something wrong when compiling libodbc++
> rather than there is a bug. I see the similar behavior with
> TDS as well.
>
> Short of building everything from source (gentoo?), I thought
> I'd see if anyone has any ideas on what could be the problem.
>
> Has anyone run into similar issues?
>
> Thanks,
>
> Simon
>
> --
> simonsmicrophone.com
>
|