Re: DBD::ODBC: crash in ping (after disconnect)
Jeff Urlwin wrote: That's probably the best thing, but there are probably more places... After reviewing the code, I think I don't like the duplication of the henv -- but the short term patch is whenever you see a SQLFreeEnv, also set the imp_dbh->henv to SQL_NULL_ENV. Sorry I haven't looked at better than that, but that resolves it for me. I've patched my svn copy and committed. I've also patched my t\05meth.t to add your tests. Can you use the svn source to test? Yes, and it works: D:\prj\DBD-ODBC\trunk>perl -w -Mblib t\05meth.t Using D:/prj/DBD-ODBC/trunk/blib 1..13 ok 1 - use DBI; ok 2 - delete prepared statement ok 3 - Number of rows > 0 ok 4 - Number of rows from DBI matches sth ok 5 - finished and rolled back ok 6 - no error ok 7 - ? ok 8 - ?? ok 9 - Active ok 10 - ping ok 11 - disconnect ok 12 - Active ok 13 - ping Steffen
RE: DBD::ODBC: crash in ping (after disconnect)
That's probably the best thing, but there are probably more places... After reviewing the code, I think I don't like the duplication of the henv -- but the short term patch is whenever you see a SQLFreeEnv, also set the imp_dbh->henv to SQL_NULL_ENV. Sorry I haven't looked at better than that, but that resolves it for me. I've patched my svn copy and committed. I've also patched my t\05meth.t to add your tests. Can you use the svn source to test? Thanks, Jeff > -Original Message- > From: Steffen Goeldner [mailto:[EMAIL PROTECTED] > Sent: Monday, February 07, 2005 5:02 AM > Cc: Martin J. Evans; [EMAIL PROTECTED]; dbi-dev@perl.org > Subject: Re: DBD::ODBC: crash in ping (after disconnect) > > > Steffen Goeldner wrote: > > > O.k., attached. Looks like SQLError receives a freed SQL_HANDLE_ENV. > > Not sure, but I think I fixed the problem. > In dbd_db_login6, I found: > > imp_dbh->henv = imp_drh->henv;/* needed for dbd_error */ > > In dbd_db_disconnect, I found: > >imp_drh->henv = SQL_NULL_HENV; > > and added > >imp_dbh->henv = SQL_NULL_HENV; > > At least my test script no longer crashes. > > > Steffen >
Re: DBD::ODBC: crash in ping (after disconnect)
Steffen Goeldner wrote: O.k., attached. Looks like SQLError receives a freed SQL_HANDLE_ENV. Not sure, but I think I fixed the problem. In dbd_db_login6, I found: imp_dbh->henv = imp_drh->henv; /* needed for dbd_error */ In dbd_db_disconnect, I found: imp_drh->henv = SQL_NULL_HENV; and added imp_dbh->henv = SQL_NULL_HENV; At least my test script no longer crashes. Steffen
Re: DBD::ODBC: crash in ping (after disconnect)
Martin J. Evans wrote: Caught a SIGSEGV at C:/opt/perl/site/lib/DBD/ODBC.pm line 208 That is the tables call in the ping method. The only time you only have an environment handle dbd_error: err_rc=-1 rc=0 s/d/e: 0/0/21631648 is when not connected to the DSN. The driver manager is supposed to handle this. How can ping be called when there is no connection? i.e. the 0 for s/d. My test script explicitly calls ping after disconnect. Surely, a normal application may accept that the 'handle is of little use after disconnecting'. But hey, it's a test script: it's purpose is to ask for trouble. Perhaps an ODBC trace would be useful. You can turn this on from the ODBC driver manager tracing tab. O.k., attached. Looks like SQLError receives a freed SQL_HANDLE_ENV. Steffen perl 02cxn e64-d44 ENTER SQLAllocHandle SQLSMALLINT 1 SQLHANDLE SQLHANDLE * 013B744C perl 02cxn e64-d44 EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 1 SQLHANDLE SQLHANDLE * 0x013B744C ( 0x014a1540) perl 02cxn e64-d44 ENTER SQLSetEnvAttr SQLHENV 014A1540 SQLINTEGER 200 SQLPOINTER 0x0003 SQLINTEGER -6 perl 02cxn e64-d44 EXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS) SQLHENV 014A1540 SQLINTEGER 200 SQLPOINTER 0x0003 (BADMEM) SQLINTEGER -6 perl 02cxn e64-d44 ENTER SQLAllocHandle SQLSMALLINT 2 SQLHANDLE 014A1540 SQLHANDLE * 013B5474 perl 02cxn e64-d44 EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 2 SQLHANDLE 014A1540 SQLHANDLE * 0x013B5474 ( 0x014a15e8) perl 02cxn e64-d44 ENTER SQLDriverConnectW HDBC014A15E8 HWND WCHAR * 0x1F7A9D2C [ -3] "**\ 0" SWORD -3 WCHAR * 0x1F7A9D2C SWORD2 SWORD * 0x UWORD0 perl 02cxn e64-d44 EXIT SQLDriverConnectW with return code -1 (SQL_ERROR) HDBC014A15E8 HWND WCHAR * 0x1F7A9D2C [ -3] "**\ 0" SWORD -3 WCHAR * 0x1F7A9D2C SWORD2 SWORD * 0x UWORD0 DIAG [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified (0) DIAG [01S00] [Microsoft][ODBC Driver Manager] Invalid connection string attribute (0) perl 02cxn e64-d44 ENTER SQLErrorW HENV014A1540 HDBC014A15E8 HSTMT WCHAR * 0x0012ED04 (NYI) SDWORD *0x0012EF40 WCHAR * 0x0012E904 SWORD 511 SWORD * 0x0012EF46 perl 02cxn e64-d44 EXIT SQLErrorW with return code 0 (SQL_SUCCESS) HENV014A1540 HDBC014A15E8 HSTMT WCHAR * 0x0012ED04 (NYI) SDWORD *0x0012EF40 (0) WCHAR * 0x0012E904 [ 91] "[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified" SWORD 511 SWORD * 0x0012EF46 (91) perl 02cxn e64-d44 ENTER SQLErrorW HENV014A1540 HDBC014A15E8 HSTMT WCHAR * 0x0012ED04 (NYI) SDWORD *0x0012EF40 WCHAR * 0x0012E904 SWORD 511 SWORD * 0x0012EF46 perl 02cxn e64-d44 EXIT SQLErrorW with return code 0 (SQL_SUCCESS) HENV014A1540 HDBC014A15E8 HSTMT WCHAR * 0x0012ED04 (NYI) SDWORD *0x001
RE: DBD::ODBC: crash in ping (after disconnect)
Hi, Caught a SIGSEGV at C:/opt/perl/site/lib/DBD/ODBC.pm line 208 That is the tables call in the ping method. The only time you only have an environment handle dbd_error: err_rc=-1 rc=0 s/d/e: 0/0/21631648 is when not connected to the DSN. The driver manager is supposed to handle this. How can ping be called when there is no connection? i.e. the 0 for s/d. Perhaps an ODBC trace would be useful. You can turn this on from the ODBC driver manager tracing tab. BTW, your code works for me to MS SQL Server dsn but from older DBI/DBD::ODBC. Martin On 19-Jan-2005 Steffen Goeldner wrote: > Hi Jeff, > > I have the following test script: > >use sigtrap; >use DBI(); >use Test::More tests => 5; > >my $dbh = DBI->connect or die $DBI::errstr; > >ok( $dbh->{$_}, $_) for 'Active'; >ok( $dbh-> $_ , $_) for 'ping'; >ok( $dbh-> $_ , $_) for 'disconnect'; >ok(!$dbh->{$_}, $_) for 'Active'; >ok(!$dbh-> $_ , $_) for 'ping';; > > which I run (accidentally) with > >DBI_DSN=dbi:ODBC:test > > and got > >ok 1 - Active >ok 2 - ping >ok 3 - disconnect >ok 4 - Active >Caught a SIGSEGV at C:/opt/perl/site/lib/DBD/ODBC.pm line 208 > > The trace shows > >dbd_error: err_rc=-1 rc=0 s/d/e: 0/0/21631648 > > First I thought SQLError() doesn't like the NULL > handles for hdbc and hstmt, but I see dbd_error2() > 'climbs up the tree' anyway. > Do you have any ideas? > > My platform: > >Windows 2000 >perl 5.6.1 >DBD::ODBC 1.13 >DBI 1.46 > > Full trace attached. > > > Steffen -- Martin J. Evans Easysoft Ltd, UK Development
DBD::ODBC: crash in ping (after disconnect)
Hi Jeff, I have the following test script: use sigtrap; use DBI(); use Test::More tests => 5; my $dbh = DBI->connect or die $DBI::errstr; ok( $dbh->{$_}, $_) for 'Active'; ok( $dbh-> $_ , $_) for 'ping'; ok( $dbh-> $_ , $_) for 'disconnect'; ok(!$dbh->{$_}, $_) for 'Active'; ok(!$dbh-> $_ , $_) for 'ping';; which I run (accidentally) with DBI_DSN=dbi:ODBC:test and got ok 1 - Active ok 2 - ping ok 3 - disconnect ok 4 - Active Caught a SIGSEGV at C:/opt/perl/site/lib/DBD/ODBC.pm line 208 The trace shows dbd_error: err_rc=-1 rc=0 s/d/e: 0/0/21631648 First I thought SQLError() doesn't like the NULL handles for hdbc and hstmt, but I see dbd_error2() 'climbs up the tree' anyway. Do you have any ideas? My platform: Windows 2000 perl 5.6.1 DBD::ODBC 1.13 DBI 1.46 Full trace attached. Steffen DBI 1.46-ithread default trace level set to 0x0/3 (pid 3412) Note: perl is running without the recommended perl -w option 1..5 -> DBI->connect(, , ) -> DBI->install_driver(ODBC) for MSWin32 perl=5.006001 pid=3412 ruid=0 euid=0 install_driver: DBD::ODBC version 1.13 loaded from C:/opt/perl/site/lib/DBD/ODBC.pm New DBI::dr (for DBD::ODBC::dr, parent=, id=) dbih_setup_handle(DBI::dr=HASH(0x1464d8c)=>DBI::dr=HASH(0x1399378), DBD::ODBC::dr, 0, Null!) dbih_make_com(Null!, , DBD::ODBC::dr, 92, ) thr#011AF0F4 <- install_driver= DBI::dr=HASH(0x1464d8c) -> default_user in DBD::_::dr for DBD::ODBC::dr (DBI::dr=HASH(0x1464d8c)~0x1399378 undef undef HASH(0x12ed804)) thr#011AF0F4 <- default_user= ( undef undef ) [2 items] at DBI.pm line 574 via 02cxn.t line 13 -> connect for DBD::ODBC::dr (DBI::dr=HASH(0x1464d8c)~0x1399378 'test' undef HASH(0x13b5e94)) thr#011AF0F4 New DBI::db (for DBD::ODBC::db, parent=DBI::dr=HASH(0x1399378), id=) dbih_setup_handle(DBI::db=HASH(0x139933c)=>DBI::db=HASH(0x13b5e88), DBD::ODBC::db, 1467d6c, Null!) dbih_make_com(DBI::dr=HASH(0x1399378), 013B5AF0, DBD::ODBC::db, 224, ) thr#011AF0F4 SQLConnect 'test', '' SQLGetFunctions - SQL_MoreResults supported: 1 <- connect= DBI::db=HASH(0x139933c) at DBI.pm line 592 -> STORE for DBD::ODBC::db (DBI::db=HASH(0x13b5e88)~INNER 'PrintError' 1) thr#011AF0F4 DBD::ODBC unsupported attribute passed (PrintError) STORE DBI::db=HASH(0x13b5e88) 'PrintError' => 1 <- STORE= 1 at DBI.pm line 639 -> STORE for DBD::ODBC::db (DBI::db=HASH(0x13b5e88)~INNER 'AutoCommit' 1) thr#011AF0F4 <- STORE= 1 at DBI.pm line 639 -> STORE for DBD::ODBC::db (DBI::db=HASH(0x13b5e88)~INNER 'Username' undef) thr#011AF0F4 DBD::ODBC unsupported attribute passed (Username) STORE DBI::db=HASH(0x13b5e88) 'Username' => undef <- STORE= 1 at DBI.pm line 642 via 02cxn.t line 13 <> FETCH= undef ('Username' from cache) at DBI.pm line 642 <- connect= DBI::db=HASH(0x139933c) -> STORE for DBD::ODBC::db (DBI::db=HASH(0x13b5e88)~INNER 'dbi_connect_closure' CODE(0x13992a0)) thr#011AF0F4 DBD::ODBC unsupported attribute passed (dbi_connect_closure) STORE DBI::db=HASH(0x13b5e88) 'dbi_connect_closure' => CODE(0x13992a0) <- STORE= 1 at DBI.pm line 662 via 02cxn.t line 13 -> FETCH for DBD::ODBC::db (DBI::db=HASH(0x13b5e88)~INNER 'Active') thr#011AF0F4 .. FETCH DBI::db=HASH(0x13b5e88) 'Active' = 1 <- FETCH= 1 at More.pm line 281 via 02cxn.t line 15 ok 1 - Active -> ping for DBD::ODBC::db (DBI::db=HASH(0x139933c)~0x13b5e88) thr#011AF0F4 New DBI::st (for DBD::ODBC::st, parent=DBI::db=HASH(0x13b5e88), id=) dbih_setup_handle(DBI::st=HASH(0x13b5f3c)=>DBI::st=HASH(0x1397304), DBD::ODBC::st, 1397250, Null!) dbih_make_com(DBI::db=HASH(0x13b5e88), 01397118, DBD::ODBC::st, 212, ) thr#011AF0F4 Tables result 0 () dbd_error: err_rc=0 rc=0 s/d/e: 21633456/21631816/21631648 dbd_error: err_rc=0 rc=0 s/d/e: 0/21631816/21631648 dbd_error: err_rc=0 rc=0 s/d/e: 0/0/21631648 build_results sql f21633456 SQLTables(,,NOXXTABLE,) dbd_describe sql 21633456: num_fields=5 col 1: VARCHAR (12) len=255 disp=256, prec=255 scale=0 col 2: VARCHAR (12) len=128 disp=129, prec=128 scale=0 col 3: VARCHAR (12) len=128 disp=129, prec=128 scale=0 col 4: VARCHAR (12) len=128 disp=129, prec=128 scale=0 col 5: VARCHAR (12) len=254 disp=255, prec=254 scale=0 col 1: 'TABLE_CAT' sqltype=VARCHAR, ctype=SQL_C_CHAR, maxlen=256, (dp = 0, cp = 0) col 2: 'TABLE_SCHEM' sqltype=VARCHAR, ctype=SQL_C_CHAR, maxlen=129, (dp = 256, cp = 10) col 3: 'TABLE_NAME' sqltype=VARCHAR, ctype=SQL_C_CHAR, maxlen=129, (dp = 388, cp = 22) col 4: 'TABLE_TYPE' sqltype=VARCHAR, ctype=SQL_C_CHAR, maxlen=129, (dp = 520, cp = 33) col 5: 'REMARKS' sqltype=VARCHAR, ctype=SQL_C_CHAR, maxlen=255, (dp = 652, cp = 44) dbd_describe build_results #2...! dbd_error: err_rc=0 rc=0 s/d/e: 21633456/21631816/21631648 dbd_error: err_rc=0 rc=0 s/d/e: 0/21631816/21631648 dbd_error: err_