subject:"DBD\:\:ODBC\: crash in ping \(after disconnect\)"

Re: DBD::ODBC: crash in ping (after disconnect)

2005-02-08 Thread Steffen Goeldner

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\trunkperl -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)

2005-02-07 Thread Steffen Goeldner

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)

2005-01-20 Thread Steffen Goeldner

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 SQL_HANDLE_ENV
SQLHANDLE   
SQLHANDLE * 013B744C

perl 02cxn  e64-d44 EXIT  SQLAllocHandle  with return code 0 (SQL_SUCCESS)
SQLSMALLINT  1 SQL_HANDLE_ENV
SQLHANDLE   
SQLHANDLE * 0x013B744C ( 0x014a1540)

perl 02cxn  e64-d44 ENTER SQLSetEnvAttr 
SQLHENV 014A1540
SQLINTEGER 200 SQL_ATTR_ODBC_VERSION
SQLPOINTER  0x0003
SQLINTEGER  -6 

perl 02cxn  e64-d44 EXIT  SQLSetEnvAttr  with return code 0 (SQL_SUCCESS)
SQLHENV 014A1540
SQLINTEGER 200 SQL_ATTR_ODBC_VERSION
SQLPOINTER  0x0003 (BADMEM)
SQLINTEGER  -6 

perl 02cxn  e64-d44 ENTER SQLAllocHandle 
SQLSMALLINT  2 SQL_HANDLE_DBC
SQLHANDLE   014A1540
SQLHANDLE * 013B5474

perl 02cxn  e64-d44 EXIT  SQLAllocHandle  with return code 0 (SQL_SUCCESS)
SQLSMALLINT  2 SQL_HANDLE_DBC
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 SQL_DRIVER_NOPROMPT

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 SQL_DRIVER_NOPROMPT

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

DBD::ODBC: crash in ping (after disconnect)

2005-01-19 Thread Steffen Goeldner

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_rc=0 rc=0 s/d/e: 0/0/21631648
-

RE: DBD::ODBC: crash in ping (after disconnect)

2005-01-19 Thread Martin J. Evans

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

Re: DBD::ODBC: crash in ping (after disconnect)

Re: DBD::ODBC: crash in ping (after disconnect)

Re: DBD::ODBC: crash in ping (after disconnect)

DBD::ODBC: crash in ping (after disconnect)

RE: DBD::ODBC: crash in ping (after disconnect)

5 matches

Site Navigation

Mail list logo

Footer information