Thread: [libodbcxx-devel] segmentation fault help please

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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