You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(43) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(28) |
Feb
(6) |
Mar
(13) |
Apr
(10) |
May
(12) |
Jun
(14) |
Jul
(12) |
Aug
|
Sep
(32) |
Oct
(8) |
Nov
(6) |
Dec
(25) |
| 2005 |
Jan
(3) |
Feb
(26) |
Mar
(1) |
Apr
(40) |
May
(6) |
Jun
(2) |
Jul
(9) |
Aug
(5) |
Sep
(24) |
Oct
(8) |
Nov
(21) |
Dec
(6) |
| 2006 |
Jan
(17) |
Feb
(10) |
Mar
(3) |
Apr
|
May
(18) |
Jun
(2) |
Jul
(9) |
Aug
(4) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2007 |
Jan
|
Feb
|
Mar
(1) |
Apr
(8) |
May
(2) |
Jun
|
Jul
(4) |
Aug
(2) |
Sep
(29) |
Oct
(15) |
Nov
(1) |
Dec
(1) |
| 2008 |
Jan
(2) |
Feb
|
Mar
(6) |
Apr
(1) |
May
(4) |
Jun
(13) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
(5) |
Nov
(7) |
Dec
(1) |
| 2009 |
Jan
(9) |
Feb
(4) |
Mar
(2) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
(11) |
Oct
(4) |
Nov
|
Dec
(20) |
| 2010 |
Jan
(9) |
Feb
(1) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
(8) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
(5) |
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(2) |
Jun
(10) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Amrit S. K. <hi4...@gm...> - 2018-12-28 02:54:50
|
Hi Team, Thank you for the wonderful job, you are doing as part of libodbc++ project. I was wondering if you guys have been supporting Informix bson and json datatypes as part of result set handling in any version. Please let me know.I am currently using v0.2.3 where the json data type is not included. If not, is there any plan to support it in near future. Thanks again. Keep up the good work. Regards, Amrit |
|
From: Pete <pe...@ka...> - 2013-06-22 02:05:06
|
I sent you an example. Did you use it at all? _____ From: tang [mailto:tan...@qq...] Sent: Saturday, 22 June 2013 12:34 p.m. To: libodbcxx-devel Subject: [libodbcxx-devel] libodbcxx not continue fix bug? |
|
From: Mark K. <gre...@ma...> - 2013-06-08 18:07:36
|
Did the sample from Pete help at all? On Jun 07, 2013, at 08:39 PM, tang <tan...@qq...> wrote: please help me to fix bug ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ libodbcxx-devel mailing list lib...@li... https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel |
|
From: t. <tan...@qq...> - 2013-06-08 00:39:20
|
please help me to fix bug |
|
From: t. <tan...@qq...> - 2013-05-31 01:57:09
|
i use sql server image field to store a file, for example inte.exe ,it's have 500M and more,i store it by setbinarystream,but i use getbinarystream to retreive image field,just 8k retreived.
please help me
ODBCXX_STREAM* bitmigStream = result->getBinaryStream("bitmig");
if (bitmigStream->good())
{
std::ofstream outExe;
outExe.open("d:\\i.exe",std::ios::out|std::ios::binary);
if (outExe.good())
{
char Buffer[1024];
while (true)
{
ZeroMemory(Buffer,sizeof(Buffer));
int readed = odbc::readStream(bitmigStream,Buffer,sizeof(Buffer));
if (!bitmigStream->eof())
{
outExe.write(Buffer,readed);
}
else
{
break;
}
}
outExe.flush();
outExe.close();
}
} |
|
From: simone p. <sim...@gm...> - 2013-01-17 22:18:07
|
Dear Users, I am still experiencing problems with building my projects with a x64 configuration and Visual Studio10.The compiler complains for the absence of the header config.h. Is there an available version for this Windows platform ? Thanks in advance |
|
From: simone p. <sim...@gm...> - 2013-01-11 20:46:59
|
In particular, When you are using libodbc in a 64 bit project and set the preprocessor to win64, the compiler will not find config.hpp any more On 11 January 2013 21:18, simone pilozzi <sim...@gm...> wrote: > I answered another question. > Indeed it is not working, the build fails with 64bit (I found only a win32 > guide). > It would be great to have a few tips on how compiling in 64 bit. > Thanks > On 11 January 2013 15:30, simone pilozzi <sim...@gm...> wrote: > >> Unfortunately it is not the case but I solved downloading directly the >> binaries from http://boost.teeks99.com/ >> Thanks to all >> >> >> On 11 January 2013 14:21, Mark Kromis <gre...@ma...> wrote: >> >>> If your app is compiled to 32 bit, then nothing changes. >>> If you compile to 64 bit, then it should work, but I have not tested it. >>> >>> On Jan 11, 2013, at 3:30 AM, simone pilozzi wrote: >>> >>> > Dear users, >>> > I am switching my machine to a 64 bit platform from 32. A lot of >>> projects are using the libodibc library to connect with sql databases. >>> > The question is if they will compile and work with the new platform or >>> if a should do some change to the projects to make them work correctely. >>> > Thanks in advance >>> > >>> ------------------------------------------------------------------------------ >>> > Master HTML5, CSS3, ASP.NET <http://asp.net/>, MVC, AJAX, >>> Knockout.js, Web API and >>> > much more. Get web development skills now with LearnDevNow - >>> > 350+ hours of step-by-step video tutorials by Microsoft MVPs and >>> experts. >>> > SALE $99.99 this month only -- learn more at: >>> > >>> http://p.sf.net/sfu/learnmore_122812_______________________________________________ >>> > libodbcxx-devel mailing list >>> > lib...@li... >>> > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Master HTML5, CSS3, ASP.NET <http://asp.net/>, MVC, AJAX, Knockout.js, >>> Web API and >>> much more. Get web development skills now with LearnDevNow - >>> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. >>> SALE $99.99 this month only -- learn more at: >>> http://p.sf.net/sfu/learnmore_122812 >>> _______________________________________________ >>> libodbcxx-devel mailing list >>> lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel >>> >> >> > |
|
From: simone p. <sim...@gm...> - 2013-01-11 20:19:04
|
I answered another question. Indeed it is not working, the build fails with 64bit (I found only a win32 guide). It would be great to have a few tips on how compiling in 64 bit. Thanks On 11 January 2013 15:30, simone pilozzi <sim...@gm...> wrote: > Unfortunately it is not the case but I solved downloading directly the > binaries from http://boost.teeks99.com/ > Thanks to all > > > On 11 January 2013 14:21, Mark Kromis <gre...@ma...> wrote: > >> If your app is compiled to 32 bit, then nothing changes. >> If you compile to 64 bit, then it should work, but I have not tested it. >> >> On Jan 11, 2013, at 3:30 AM, simone pilozzi wrote: >> >> > Dear users, >> > I am switching my machine to a 64 bit platform from 32. A lot of >> projects are using the libodibc library to connect with sql databases. >> > The question is if they will compile and work with the new platform or >> if a should do some change to the projects to make them work correctely. >> > Thanks in advance >> > >> ------------------------------------------------------------------------------ >> > Master HTML5, CSS3, ASP.NET <http://asp.net/>, MVC, AJAX, Knockout.js, >> Web API and >> > much more. Get web development skills now with LearnDevNow - >> > 350+ hours of step-by-step video tutorials by Microsoft MVPs and >> experts. >> > SALE $99.99 this month only -- learn more at: >> > >> http://p.sf.net/sfu/learnmore_122812_______________________________________________ >> > libodbcxx-devel mailing list >> > lib...@li... >> > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel >> >> >> >> ------------------------------------------------------------------------------ >> Master HTML5, CSS3, ASP.NET <http://asp.net/>, MVC, AJAX, Knockout.js, >> Web API and >> much more. Get web development skills now with LearnDevNow - >> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. >> SALE $99.99 this month only -- learn more at: >> http://p.sf.net/sfu/learnmore_122812 >> _______________________________________________ >> libodbcxx-devel mailing list >> lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel >> > > |
|
From: simone p. <sim...@gm...> - 2013-01-11 14:30:38
|
Unfortunately it is not the case but I solved downloading directly the binaries from http://boost.teeks99.com/ Thanks to all On 11 January 2013 14:21, Mark Kromis <gre...@ma...> wrote: > If your app is compiled to 32 bit, then nothing changes. > If you compile to 64 bit, then it should work, but I have not tested it. > > On Jan 11, 2013, at 3:30 AM, simone pilozzi wrote: > > > Dear users, > > I am switching my machine to a 64 bit platform from 32. A lot of > projects are using the libodibc library to connect with sql databases. > > The question is if they will compile and work with the new platform or > if a should do some change to the projects to make them work correctely. > > Thanks in advance > > > ------------------------------------------------------------------------------ > > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > > much more. Get web development skills now with LearnDevNow - > > 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > > SALE $99.99 this month only -- learn more at: > > > http://p.sf.net/sfu/learnmore_122812_______________________________________________ > > libodbcxx-devel mailing list > > lib...@li... > > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > > > > ------------------------------------------------------------------------------ > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812 > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > |
|
From: Mark K. <gre...@ma...> - 2013-01-11 13:23:19
|
If your app is compiled to 32 bit, then nothing changes. If you compile to 64 bit, then it should work, but I have not tested it. On Jan 11, 2013, at 3:30 AM, simone pilozzi wrote: > Dear users, > I am switching my machine to a 64 bit platform from 32. A lot of projects are using the libodibc library to connect with sql databases. > The question is if they will compile and work with the new platform or if a should do some change to the projects to make them work correctely. > Thanks in advance > ------------------------------------------------------------------------------ > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812_______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel |
|
From: simone p. <sim...@gm...> - 2013-01-11 08:30:11
|
Dear users, I am switching my machine to a 64 bit platform from 32. A lot of projects are using the libodibc library to connect with sql databases. The question is if they will compile and work with the new platform or if a should do some change to the projects to make them work correctely. Thanks in advance |
|
From: Simon W. <si...@gi...> - 2012-06-19 02:23:53
|
On 06/08/2012 09:48 AM, Buck Huppmann wrote: > > On Wed, Jun 06, 2012 at 08:01:48PM -0900, Simon Walter wrote: >> >> On 06/07/2012 01:34 PM, Buck wrote: >>> >>> looks like the ``leak'' is in the C library's getpwuid(), which allocates >>> a ``static buffer'' for the returned struct passwd, no? if you're suggest- >>> ing that libodbc should call (the reentrant, and non-static struct passwd- >>> returning) getpwuid_r() directly, then you need to talk to the unixODBC >>> folks. but if you're saying GNU libc's getpwuid() should clean up at exit >>> or something, that's a different political arena >>> >>> anyways, thanks for sussing out the correct release semantics for the var- >>> ious libodbc++ objects >> >> Hi Buck, >> >> Thanks for setting me straight. I'm relatively new to c/c++ development >> on nix platforms and wasn't sure what I was seeing. I'm kind of >> surprised/annoyed that things are in this state - at least on Debian. It >> affects multi-threaded applications quite a bit. If I can't get them to >> sort it out, I'll have to steer clear of unixODBC for now. Or maybe use >> a different OS. > > Dang. 5,192 bytes over the lifetime of a process that get reclaimed at > process exit is that big a price to pay? > > cause, at least from glancing at > > http://sourceware.org/git/?p=glibc.git;a=blob;f=nss/getXXbyYY.c;h=336676ad555a0e7905318a11bbd0f9fc57fe8793;hb=HEAD > > it seems to me that it's 1 buffer per process and not per thread, so you > can spin up as many threads as you like and not ever leak more than that, > whereas i'd wager that another OS' process/thread/related kernel/subsys- > tem's object's overhead is gonna have a bigger footprint than that Sorry I've been sick with some kind of food poisoning. Better now. I must have sent the wrong trace. When using a MySQL db via ODBC, I was losing 4 bytes for every connect and disconnect. I built the MySQL ODBC driver from source, and it seems to crash less. It still crashes occasionally. It seems the problem is primarily with the driver. I'm going to try this on another platform - currently Debian 6. Cheers, Simon -- simonsmicrophone.com |
|
From: Simon W. <si...@gi...> - 2012-06-07 05:03:23
|
On 06/07/2012 12:39 PM, Pete wrote: > Hi Simon, > > I'm not familiar with unique_ptr and used auto_ptr instead. I also isolated > db I/O part into a function. > > Tell me if this works fine now. It acts the same way. As Buck pointed out, it looks like the trouble is with unixODBC. Thanks for your help though. I'll see if I can't persuade Debian to package a newer version. Cheers, Simon -- simonsmicrophone.com |
|
From: Simon W. <si...@gi...> - 2012-06-07 05:02:27
|
On 06/07/2012 01:34 PM, Buck wrote: > > looks like the ``leak'' is in the C library's getpwuid(), which allocates > a ``static buffer'' for the returned struct passwd, no? if you're suggest- > ing that libodbc should call (the reentrant, and non-static struct passwd- > returning) getpwuid_r() directly, then you need to talk to the unixODBC > folks. but if you're saying GNU libc's getpwuid() should clean up at exit > or something, that's a different political arena > > anyways, thanks for sussing out the correct release semantics for the var- > ious libodbc++ objects Hi Buck, Thanks for setting me straight. I'm relatively new to c/c++ development on nix platforms and wasn't sure what I was seeing. I'm kind of surprised/annoyed that things are in this state - at least on Debian. It affects multi-threaded applications quite a bit. If I can't get them to sort it out, I'll have to steer clear of unixODBC for now. Or maybe use a different OS. Cheers, Simon -- simonsmicrophone.com |
|
From: Pete <pe...@ka...> - 2012-06-07 03:40:07
|
Hi Simon,
I'm not familiar with unique_ptr and used auto_ptr instead. I also isolated
db I/O part into a function.
Tell me if this works fine now.
Pete
> -----Original Message-----
> From: Simon Walter [mailto:si...@gi...]
> Sent: Thursday, 7 June 2012 1:09 p.m.
> To: lib...@li...
> Subject: Re: [libodbcxx-devel] segmentation fault help please
>
>
> 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
>
> --------------------------------------------------------------
> ----------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security
> and threat landscape has changed and how IT managers can
> respond. Discussions will include endpoint security, mobile
> security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> libodbcxx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel
>
|
|
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
|
|
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
>
|
|
From: Jan B. <jbr...@ya...> - 2012-06-06 09:44:02
|
Hi Simon, it seems that your delete-statements have the wrong order: A connection deletes all its statements when it is deleted and a statement deletes its last result set when it is deleted. Consequently, your statement and resultset are deleted twice. Just delete your connection and it should work. I must admit, that I did not test your code with the above mentioned change, so there might be further problems. Regards, Jan |
|
From: Simon W. <si...@gi...> - 2012-06-06 05:44:30
|
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
|
|
From: Simon W. <si...@gi...> - 2012-06-04 10:47:42
|
On 05/24/2012 09:55 PM, Mark Kromis wrote: > > Do you have a sample? I will look into it some more. I found out that had to do with the driver threading setting which is documented in __handles.c. I set the threading setting to 0, which is supposed to be supported and the default in the latest versions of unixodbc. However, when doing so, I get a SIGABRT and sometimes a SIGSEGV. I've sent a report to the mysql odbc mailing list. I'll see what they say. In the meantime, as it might be related to libodbc++, I'll include the backtraces with this email. Cheers, Simon -- simonsmicrophone.com |
|
From: Mark K. <gre...@ma...> - 2012-05-24 12:55:34
|
Do you have a sample? I will look into it some more. On May 23, 2012, at 1:55 AM, Simon Walter wrote: > When using the MySQL ODBC driver in a threaded application, I always get > the error message: > Error in my_thread_global_end(): 1 threads didn't exit > > I found something about this on the MySQL mailing list: > http://article.gmane.org/gmane.comp.db.mysql.odbc/6058/match=my_thread_global_end > > It looks like it's a known bug. I just wanted to confirm with other > users and what the potential issues are of this error. > > Cheers, > > Simon > > -- > simonsmicrophone.com > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel |
|
From: Simon W. <si...@gi...> - 2012-05-23 05:54:25
|
When using the MySQL ODBC driver in a threaded application, I always get the error message: Error in my_thread_global_end(): 1 threads didn't exit I found something about this on the MySQL mailing list: http://article.gmane.org/gmane.comp.db.mysql.odbc/6058/match=my_thread_global_end It looks like it's a known bug. I just wanted to confirm with other users and what the potential issues are of this error. Cheers, Simon -- simonsmicrophone.com |
|
From: Simon W. <si...@gi...> - 2012-04-30 03:09:26
|
Hi Pete,
Thank you very much for the detailed example. I've taken a look at how
you've done it and the only difference I can see is that I was using
odbc::PreparedStatement.
> I'm not sure what you mean by:
>
>> I can use the same odbc::DriverManager that I used with the
>> first query but not odbc::Connection or odbc::PreparedStatement.
Regarding recycling the objects and connection. I could not reuse the
connection. As you say, reusing the statement is pointless. So I'll
forget about doing that.
So I must be doing something incorrectly with PreparedStatment. Perhaps
there is some kind of initialization or cleanup required when using
PreparedStatment? I cannot reuse the connection after using executing a
PreparedStatment. I don't get any results back.
// For example:
odbc::Connection *connection =
odbc::DriverManager::getConnection(dbConnectString);
std::stringstream query;
query << "select ...";
odbc::PreparedStatement *statement =
connection->prepareStatement(query.str());
statement->execute();
query.str("");
query << "select ...";
odbc::PreparedStatement *statement2 =
connection->prepareStatement(query.str());
statement2->execute();
delete connection;
delete statement;
delete statement2;
// end
The statement2 has no results. Though I can see the statement reaching
the DB by using MS SQL Server Profiler. I wonder if I should be
resetting the connection or something similar when using prepared
statements and callable statements.
In any case, at least regular statements work with successive calls. I'm
curious about callable and prepared statements as I use callable for
stored procedures and imagine I'll have use cases for prepared statements.
Many thanks for your help,
Simon
--
simonsmicrophone.com
|
|
From: Pete <pe...@ka...> - 2012-04-27 02:05:05
|
Hi Simon, I'm not sure what you mean by: > I can use the same odbc::DriverManager that I used with the > first query but not odbc::Connection or odbc::PreparedStatement. Attached is a little example that iterates over all orders in my database and while fetching each order from the result set, goes to the database and gets the related customers name by using the same connection, creating a new statement and processing the result from another query. This is also called "Multiple active result sets" or MARS. My test works with Orcle too. I'm sure you'll find it easy to adjust the sample to your database. You may notice my use of smart pointers which keep the code clean and simple. Also, recycling ako odbc::Statement objects makes little sense since they load meta data and establish fetch handlers so there is hardly a case for recycling. Pete > -----Original Message----- > From: Simon Walter [mailto:si...@gi...] > Sent: Thursday, 26 April 2012 2:01 p.m. > To: lib...@li... > Subject: [libodbcxx-devel] Can I reuse connections, statements? > > Hi all, > > I'm making a two successive queries to a DB. The second one > does not return any results unless I create a new connection. > I also cannot reuse a statement object. > > If this is by design and the way the library works, that's > fine. I just want make sure I'm not using it wrong. > > I can use the same odbc::DriverManager that I used with the > first query but not odbc::Connection or odbc::PreparedStatement. > > Cheers, > > Simon > > PS > > One comment about the documentation, which is overall excellent: > > odbc::Date::getTime indicates that only the time part of the > date is returned as time_t, when actually the entire date is > returned as time_t. > > "/Returns the time_t value of |00:00:00| at this date."/ > > Perhaps: "Returns the time_t value of this date." would be clearer. > > http://libodbcxx.sourceforge.net/libodbc++/progref/classodbc_1 > _1_date.html#a8 > > -- > simonsmicrophone.com > > > -------------------------------------------------------------- > ---------------- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the > latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > |
|
From: Simon W. <si...@gi...> - 2012-04-26 02:01:17
|
Hi all, I'm making a two successive queries to a DB. The second one does not return any results unless I create a new connection. I also cannot reuse a statement object. If this is by design and the way the library works, that's fine. I just want make sure I'm not using it wrong. I can use the same odbc::DriverManager that I used with the first query but not odbc::Connection or odbc::PreparedStatement. Cheers, Simon PS One comment about the documentation, which is overall excellent: odbc::Date::getTime indicates that only the time part of the date is returned as time_t, when actually the entire date is returned as time_t. "/Returns the time_t value of |00:00:00| at this date."/ Perhaps: "Returns the time_t value of this date." would be clearer. http://libodbcxx.sourceforge.net/libodbc++/progref/classodbc_1_1_date.html#a8 -- simonsmicrophone.com |