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 > |