Bug #46628 for DBD-Oracle: bind_param_inout ORA_RSET causes MSWin32 access violation

Tue Jun 02 16:25:01 2009 jeff.holt [...] method-r.com - Ticket created

Subject:

bind_param_inout ORA_RSET causes MSWin32 access violation

The attached test script causes an access violation on MSWin32 when an anonymous PL/SQL block execution has an optional sys_refcursor. The PL/SQL code could open the refcursor but does not. When it does not and you execute it, then a subsequent bind_param_inout will cause the access violation. An real example of when this might happen is if an exception is raised before the sys_refcursor is opened. My Oracle client version is 11.1.0.7. I applied the fix for bug #46246 (which actually did fix that bug given the supplied repro) but it did not fix this problem. Thanks.

Subject:

52cursor.t

use Test::More; use DBI; use DBD::Oracle qw(ORA_RSET); use strict; unshift @INC ,'t'; require 'nchar_test_lib.pl'; plan tests => 4; my $dsn = oracle_test_dsn(); my $dbuser = $ENV{ORACLE_USERID} || 'scott/tiger'; my $dbh = DBI->connect($dsn, $dbuser, '', { PrintError => 0 }); my $sth0 = $dbh->prepare(qq{ BEGIN IF FALSE THEN OPEN :r FOR SELECT * FROM dual; END IF; END; }); ok($sth0, 'open cursor'); my $sth1; ok($sth0->bind_param_inout(":r", \$sth1, 0, {ora_type=>ORA_RSET}), 'bind'); ok($sth0->execute, 'first execute'); ok($sth0->execute, 'second execute'); $dbh->disconnect; exit 0;

Wed Jun 03 00:09:44 2009 jeff.holt [...] method-r.com - Correspondence added

From:

jeff.holt [...] method-r.com

Death is occurring in dbd_st_finish when OCIStmtFetch_log_stat, a macro for OCIStmtFetch2, is executed. I'm pretty sure that it's the sys_refcursor handle that's being cleaned up when the second $sth0->execute is executed. I commented out the "buggy" call to OCIStmtFetch_log_stat and the subsequent 'if'. This had no effect on existing tests (which is odd) and it did fix my bug. I'll admit that there were some skipped tests (10general, 23wide*, 30long, 60reauth) but those don't appear to be exercising this now-commented code. I'm having difficulty understanding why this small bit of code was added without a test to cover it. It seems to be in a critical path and that's why I consider it odd that commenting it out didn't cause any tests to fail. At any rate, I don't like the fact that the fetch is in this function but I've a horrible headache and can't stomach the blame to find out why it's there. Can someone enlighten me, please?

Mon Nov 26 15:31:16 2012 champoux [...] pythian.com - Correspondence added

I don't know enough about what is going on here to try to fix the problem, but I tried the 52cursor.t test (with RaiseError => 1) and got $ perl t/52cursor.t 1..4 ok 1 - open cursor ok 2 - bind DBD::Oracle::st execute failed: ORA-24338: statement handle not executed (DBD ERROR: OCIAttrGet OCI_ATTR_PARAM_COUNT) [for Statement " BEGIN IF FALSE THEN OPEN :r FOR SELECT * FROM dual; END IF; END; " with ParamValues: :r=DBI::st=HASH(0x9a98528)] at t/52cursor.t line 27. DBD::Oracle::st execute failed: ORA-24338: statement handle not executed (DBD ERROR: OCIAttrGet OCI_ATTR_PARAM_COUNT) [for Statement " BEGIN IF FALSE THEN OPEN :r FOR SELECT * FROM dual; END IF; END; " with ParamValues: :r=DBI::st=HASH(0x9a98528)] at t/52cursor.t line 27. # Looks like you planned 4 tests but ran 2. # Looks like your test exited with 255 just after 2.

Mon Nov 26 15:31:17 2012 The RT System itself - Status changed from 'new' to 'open'

Sat Jan 12 12:35:33 2013 bohica [...] ntlworld.com - Correspondence added

On Wed Jun 03 00:09:44 2009, jeff.holt@method-r.com wrote: Show quoted text

> Death is occurring in dbd_st_finish when OCIStmtFetch_log_stat, a macro > for OCIStmtFetch2, is executed. > > I'm pretty sure that it's the sys_refcursor handle that's being cleaned > up when the second $sth0->execute is executed. > > I commented out the "buggy" call to OCIStmtFetch_log_stat and the > subsequent 'if'. This had no effect on existing tests (which is odd) and > it did fix my bug. I'll admit that there were some skipped tests > (10general, 23wide*, 30long, 60reauth) but those don't appear to be > exercising this now-commented code. > > I'm having difficulty understanding why this small bit of code was added > without a test to cover it. It seems to be in a critical path and that's > why I consider it odd that commenting it out didn't cause any tests to

fail. Show quoted text

> > At any rate, I don't like the fact that the fetch is in this function > but I've a horrible headache and can't stomach the blame to find out why > it's there. Can someone enlighten me, please?

You may be interested in the dbi-dev discussion regarding an issue I found very similar to the one you found. You can read it at http://www.mail-archive.com/dbi-dev@perl.org/msg06963.html I'd be interested in you trying my patch to fix my problem as I think the problem you identified is very similar. If you are in a position to do that please let me know and I'll provide you with the details. If it does not fix your issue I am happy to work on that too. Martin -- Martin J. Evans Wetherby, UK

Mon Jan 14 11:01:56 2013 jeff.holt [...] method-r.com - Correspondence added

Subject:	Re: [rt.cpan.org #46628] bind_param_inout ORA_RSET causes MSWin32 access violation
Date:	Mon, 14 Jan 2013 10:01:31 -0600
To:	bug-DBD-Oracle [...] rt.cpan.org
From:	Jeff Holt <jeff.holt [...] method-r.com>

Yes, Martin. I'd be happy to try your patch and report back with what I find. I read your post and agree that your second "hack" is a better solution than your first. At the moment, I can't think of anything else to try so if it works for me then I would endorse it. On Sat, Jan 12, 2013 at 11:35 AM, Martin J Evans via RT < bug-DBD-Oracle@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=46628 > > > On Wed Jun 03 00:09:44 2009, jeff.holt@method-r.com wrote:

> > Death is occurring in dbd_st_finish when OCIStmtFetch_log_stat, a macro > > for OCIStmtFetch2, is executed. > > > > I'm pretty sure that it's the sys_refcursor handle that's being cleaned > > up when the second $sth0->execute is executed. > > > > I commented out the "buggy" call to OCIStmtFetch_log_stat and the > > subsequent 'if'. This had no effect on existing tests (which is odd) and > > it did fix my bug. I'll admit that there were some skipped tests > > (10general, 23wide*, 30long, 60reauth) but those don't appear to be > > exercising this now-commented code. > > > > I'm having difficulty understanding why this small bit of code was added > > without a test to cover it. It seems to be in a critical path and that's > > why I consider it odd that commenting it out didn't cause any tests to

> fail.

> > > > At any rate, I don't like the fact that the fetch is in this function > > but I've a horrible headache and can't stomach the blame to find out why > > it's there. Can someone enlighten me, please?

> > You may be interested in the dbi-dev discussion regarding an issue I > found very similar to the one you found. You can read it at > http://www.mail-archive.com/dbi-dev@perl.org/msg06963.html > > I'd be interested in you trying my patch to fix my problem as I think > the problem you identified is very similar. If you are in a position to > do that please let me know and I'll provide you with the details. If it > does not fix your issue I am happy to work on that too. > > Martin > -- > Martin J. Evans > Wetherby, UK >

Mon Jan 14 15:35:38 2013 bohica [...] ntlworld.com - Correspondence added

On Mon Jan 14 11:01:56 2013, jeff.holt@method-r.com wrote: Show quoted text

> Yes, Martin. I'd be happy to try your patch and report back with what I > find. I read your post and agree that your second "hack" is a better > solution than your first. At the moment, I can't think of anything else to > try so if it works for me then I would endorse it.

The only problem for me is my second patch could adversely affect anyone who was expecting a real sth although in fairness it would have failed later in the execute call calling OCIAttrGet for PARAM_COUNT (so I doubt anyone is doing that). Someone here obviously spotted this and put a false select 1 from dual into the proc where it could not return a cursor which I thought was really naff (and as you state would not work if the proc raised an error anyway). I've emailed it to dbi-dev and await responses (although I note Tim is away for a week). If I emailed you a tarball of the current subversion trunk with patch applied would this be ok for you? Ragarding the fetch issue you found in the finish/destroy method, I think this would disappear with patch 2 as you'd never have created a sth in the first place. I did not write the code you refer to and don't really get it so yet another reason why patch 2 is probably better. I can email you a patched ditrib to try later tonigh or tomorrow. Martin Show quoted text

> > On Sat, Jan 12, 2013 at 11:35 AM, Martin J Evans via RT < > bug-DBD-Oracle@rt.cpan.org> wrote: >

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=46628 > > > > > On Wed Jun 03 00:09:44 2009, jeff.holt@method-r.com wrote:

> > > Death is occurring in dbd_st_finish when OCIStmtFetch_log_stat, a

macro Show quoted text

> > > for OCIStmtFetch2, is executed. > > > > > > I'm pretty sure that it's the sys_refcursor handle that's being

cleaned Show quoted text

> > > up when the second $sth0->execute is executed. > > > > > > I commented out the "buggy" call to OCIStmtFetch_log_stat and the > > > subsequent 'if'. This had no effect on existing tests (which is

odd) and Show quoted text

> > > it did fix my bug. I'll admit that there were some skipped tests > > > (10general, 23wide*, 30long, 60reauth) but those don't appear to be > > > exercising this now-commented code. > > > > > > I'm having difficulty understanding why this small bit of code was

added Show quoted text

> > > without a test to cover it. It seems to be in a critical path and

that's Show quoted text

> > > why I consider it odd that commenting it out didn't cause any tests to

> > fail.

> > > > > > At any rate, I don't like the fact that the fetch is in this function > > > but I've a horrible headache and can't stomach the blame to find

out why Show quoted text

> > > it's there. Can someone enlighten me, please?

> > > > You may be interested in the dbi-dev discussion regarding an issue I > > found very similar to the one you found. You can read it at > > http://www.mail-archive.com/dbi-dev@perl.org/msg06963.html > > > > I'd be interested in you trying my patch to fix my problem as I think > > the problem you identified is very similar. If you are in a position to > > do that please let me know and I'll provide you with the details. If it > > does not fix your issue I am happy to work on that too. > > > > Martin > > -- > > Martin J. Evans > > Wetherby, UK > >

-- Martin J. Evans Wetherby, UK

Mon Jan 14 16:02:12 2013 jeff.holt [...] method-r.com - Correspondence added

Subject:	Re: [rt.cpan.org #46628] bind_param_inout ORA_RSET causes MSWin32 access violation
Date:	Mon, 14 Jan 2013 15:02:00 -0600
To:	bug-DBD-Oracle [...] rt.cpan.org
From:	Jeff Holt <jeff.holt [...] method-r.com>

That's fine, Martin. I can accept a tarball. On a slightly unrelated note, I thought Tim was out of the DBD support business. Didn't pythian take over? On Mon, Jan 14, 2013 at 2:35 PM, Martin J Evans via RT < bug-DBD-Oracle@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=46628 > > > On Mon Jan 14 11:01:56 2013, jeff.holt@method-r.com wrote:

> > Yes, Martin. I'd be happy to try your patch and report back with what I > > find. I read your post and agree that your second "hack" is a better > > solution than your first. At the moment, I can't think of anything else

> to

> > try so if it works for me then I would endorse it.

> > The only problem for me is my second patch could adversely affect anyone > who was expecting a real sth although in fairness it would have failed > later in the execute call calling OCIAttrGet for PARAM_COUNT (so I doubt > anyone is doing that). Someone here obviously spotted this and put a > false select 1 from dual into the proc where it could not return a > cursor which I thought was really naff (and as you state would not work > if the proc raised an error anyway). I've emailed it to dbi-dev and > await responses (although I note Tim is away for a week). If I emailed > you a tarball of the current subversion trunk with patch applied would > this be ok for you? > > Ragarding the fetch issue you found in the finish/destroy method, I > think this would disappear with patch 2 as you'd never have created a > sth in the first place. I did not write the code you refer to and don't > really get it so yet another reason why patch 2 is probably better. > > I can email you a patched ditrib to try later tonigh or tomorrow. > > Martin >

> > > > On Sat, Jan 12, 2013 at 11:35 AM, Martin J Evans via RT < > > bug-DBD-Oracle@rt.cpan.org> wrote: > >

> > > <URL: https://rt.cpan.org/Ticket/Display.html?id=46628 > > > > > > > On Wed Jun 03 00:09:44 2009, jeff.holt@method-r.com wrote:

> > > > Death is occurring in dbd_st_finish when OCIStmtFetch_log_stat, a

> macro

> > > > for OCIStmtFetch2, is executed. > > > > > > > > I'm pretty sure that it's the sys_refcursor handle that's being

> cleaned

> > > > up when the second $sth0->execute is executed. > > > > > > > > I commented out the "buggy" call to OCIStmtFetch_log_stat and the > > > > subsequent 'if'. This had no effect on existing tests (which is

> odd) and

> > > > it did fix my bug. I'll admit that there were some skipped tests > > > > (10general, 23wide*, 30long, 60reauth) but those don't appear to be > > > > exercising this now-commented code. > > > > > > > > I'm having difficulty understanding why this small bit of code was

> added

> > > > without a test to cover it. It seems to be in a critical path and

> that's

> > > > why I consider it odd that commenting it out didn't cause any tests

> to

> > > fail.

> > > > > > > > At any rate, I don't like the fact that the fetch is in this function > > > > but I've a horrible headache and can't stomach the blame to find

> out why

> > > > it's there. Can someone enlighten me, please?

> > > > > > You may be interested in the dbi-dev discussion regarding an issue I > > > found very similar to the one you found. You can read it at > > > http://www.mail-archive.com/dbi-dev@perl.org/msg06963.html > > > > > > I'd be interested in you trying my patch to fix my problem as I think > > > the problem you identified is very similar. If you are in a position to > > > do that please let me know and I'll provide you with the details. If it > > > does not fix your issue I am happy to work on that too. > > > > > > Martin > > > -- > > > Martin J. Evans > > > Wetherby, UK > > >

> > > -- > Martin J. Evans > Wetherby, UK >

Mon Jan 14 16:20:35 2013 champoux [...] pythian.com - Correspondence added

Subject:	Re: [rt.cpan.org #46628] bind_param_inout ORA_RSET causes MSWin32 access violation
Date:	Mon, 14 Jan 2013 16:20:22 -0500
To:	bug-DBD-Oracle [...] rt.cpan.org
From:	Yanick Champoux <champoux [...] pythian.com>

On 13-01-14 04:02 PM, Jeff Holt via RT wrote: Show quoted text

> On a slightly unrelated note, I thought Tim was out of the DBD support > business. Didn't pythian take over?

Kinda. We took on the maintainership of the module, but right now there is only me working (sporadically) on it. And as my DBD skills are... let's just say not up to par with the mad skillz of everybody else involved, I mostly take care of bundling the releases. :-) Joy, `/anick -- --

Tue Jan 15 06:31:53 2013 bohica [...] ntlworld.com - Correspondence added

On Mon Jan 14 16:02:12 2013, jeff.holt@method-r.com wrote: Show quoted text

> That's fine, Martin. I can accept a tarball.

Attached DBD::Oracle 1.56 (sorry I did not update the version) with patch. It also includes a new test case for 50cursor.t. First thing would be to check it passes the test suite then whatever you were doing. Show quoted text

> On a slightly unrelated note, I thought Tim was out of the DBD support > business. Didn't pythian take over?

It was more a case of getting his feedback on the change as I have 2 solutions. I help Yanick maintain DBD::Oracle when I can. Where I work we heavily depend on DBD::Oracle. You can find me on irc.perl.org #dbi (as mje) if that is more convenient if you have any issues. Martin -- Martin J. Evans Wetherby, UK

Subject:

DBD-Oracle-1.56.tar.gz

Download DBD-Oracle-1.56.tar.gz
application/x-gzip 430.5k

Message body not shown because it is not plain text.

Wed Jan 16 13:19:50 2013 jeff.holt [...] method-r.com - Correspondence added

Subject:	Re: [rt.cpan.org #46628] bind_param_inout ORA_RSET causes MSWin32 access violation
Date:	Wed, 16 Jan 2013 12:19:38 -0600
To:	bug-DBD-Oracle [...] rt.cpan.org
From:	Jeff Holt <jeff.holt [...] method-r.com>

Your version of the code passes all the tests in the distribution plus my test, 52cursor.t. I also downloaded the unpatched 1.56 code from cpan and saw my test fail. I did all this on Linux 2.6.18-92.1.13 i386, perl 5.8.8, and Oracle 11.1.0.7. I tried to test the code on MSWin32 but nmake failed (see below if you're interested). It's been too long for me working on MSWin32 to remember how to build on that platform. Even so, I clearly remember my test failed on Linux and MSWin32. It's just that the bug manifested slightly differently on the two platforms. So, my hope is that if the test passes on Linux that it will also pass on MSWin32. cl -c -IC:/ora/11.2.0/OCI/include -IC:/ora/11.2.0/rdbms/demo -IC:\perl\site\lib\auto\DBI -nologo -GF -W3 -MD -Zi -D NDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1 -DVERSION=\"1.56\" -DXS_VERSION=\"1.56\" "- IC:\Perl\lib\CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.1\" -DORA_OCI_102 -DORA_OCI_112 Oracle.c cl : Command line warning D4029 : optimization is not available in the standard edition compiler Oracle.c C:/ora\11.2.0\OCI\include\oratypes.h(18) : fatal error C1083: Cannot open include file: 'stddef.h': No such file or directory NMAKE : fatal error U1077: 'cl' : return code '0x2' On Tue, Jan 15, 2013 at 5:31 AM, Martin J Evans via RT < bug-DBD-Oracle@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=46628 > > > On Mon Jan 14 16:02:12 2013, jeff.holt@method-r.com wrote:

> > That's fine, Martin. I can accept a tarball.

> > Attached DBD::Oracle 1.56 (sorry I did not update the version) with > patch. It also includes a new test case for 50cursor.t. First thing > would be to check it passes the test suite then whatever you were doing. >

> > On a slightly unrelated note, I thought Tim was out of the DBD support > > business. Didn't pythian take over?

> > It was more a case of getting his feedback on the change as I have 2 > solutions. I help Yanick maintain DBD::Oracle when I can. Where I work > we heavily depend on DBD::Oracle. > > You can find me on irc.perl.org #dbi (as mje) if that is more convenient > if you have any issues. > > Martin > -- > Martin J. Evans > Wetherby, UK >

Wed Jan 16 15:11:56 2013 bohica [...] ntlworld.com - Correspondence added

On Wed Jan 16 13:19:50 2013, jeff.holt@method-r.com wrote: Show quoted text

> Your version of the code passes all the tests in the distribution plus my > test, 52cursor.t. I also downloaded the unpatched 1.56 code from cpan and > saw my test fail. I did all this on Linux 2.6.18-92.1.13 i386, perl 5.8.8, > and Oracle 11.1.0.7. > > I tried to test the code on MSWin32 but nmake failed (see below if you're > interested). It's been too long for me working on MSWin32 to remember how > to build on that platform. > > Even so, I clearly remember my test failed on Linux and MSWin32. It's just > that the bug manifested slightly differently on the two platforms. So, my > hope is that if the test passes on Linux that it will also pass on

MSWin32. Show quoted text

> > > cl -c -IC:/ora/11.2.0/OCI/include -IC:/ora/11.2.0/rdbms/demo > -IC:\perl\site\lib\auto\DBI -nologo -GF -W3 -MD -Zi -D > NDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT > -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_IMPLICIT_CONTEXT > -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG > -O1 -DVERSION=\"1.56\" -DXS_VERSION=\"1.56\" "- > IC:\Perl\lib\CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.1\" > -DORA_OCI_102 -DORA_OCI_112 Oracle.c > cl : Command line warning D4029 : optimization is not available in the > standard edition compiler > Oracle.c > C:/ora\11.2.0\OCI\include\oratypes.h(18) : fatal error C1083: Cannot open > include file: 'stddef.h': No such file or directory > > NMAKE : fatal error U1077: 'cl' : return code '0x2'

I'm not sure about the Windows issue as I don't use DBD::Oracle on Windows. I might find some time to look at it. Anyway, thanks for trying the patched version. I know the time this takes and as there is some difference of opinion right now as to what should happen in OCI in these circumstances (when I see no ill effects at all and the previous version was clearly broken) it gives me extra confidence to apply. I'm just waiting for replies from Charles and may be Tim next week and then hopefully I will apply it. Thanks again for the report. Sorry I didn't jump on it sooner but my focus was elsewhere. Martin -- Martin J. Evans Wetherby, UK

Tue Mar 05 05:48:30 2013 bohica [...] ntlworld.com - Status changed from 'open' to 'patched'

Wed May 22 15:12:50 2013 champoux [...] pythian.com - Status changed from 'patched' to 'resolved'

Wed May 22 16:18:39 2013 jeff.holt [...] method-r.com - Correspondence added

Subject:	Re: [rt.cpan.org #46628] Resolved: bind_param_inout ORA_RSET causes MSWin32 access violation
Date:	Wed, 22 May 2013 15:18:22 -0500
To:	bug-DBD-Oracle [...] rt.cpan.org
From:	Jeff Holt <jeff.holt [...] method-r.com>

The last status change is correct. The bug is broken in 1.56 but fixed in the attached version of 1.56 and also fixed in the latest download from CPAN, version 1.62. On Wed, May 22, 2013 at 2:12 PM, Pythian Remote DBA via RT < bug-DBD-Oracle@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=46628 > > > According to our records, your request has been resolved. If you have any > further questions or concerns, please respond to this message. >

Bug #46628 for DBD-Oracle: bind_param_inout ORA_RSET causes MSWin32 access violation

Preferred bug tracker