Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DBD-Oracle CPAN distribution.

Report information
The Basics
Id: 69350
Status: resolved
Priority: 0/
Queue: DBD-Oracle

People
Owner: champoux [...] pythian.com
Requestors: wes [...] smellycat.com
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: (no value)
Fixed in: (no value)



CC: Wes Brown <wes [...] smellycat.com>
Subject: Issue in 31lob.t for DBD::Oracle 1.28
Date: Thu, 7 Jul 2011 20:34:09 -0400
To: bug-DBD-Oracle [...] rt.cpan.org
From: Wes Brown <wes [...] smellycat.com>
Download (untitled) / with headers
text/plain 2.6k
$ perl5 -v This is perl 5, version 12, subversion 3 (v5.12.3) built for x86_64-linux-thread-multi Very similar to ID: 69305 Ran the tests for DBD::Oracle 1.28 against Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production on HP-UX from Oracle client Release 11.2.0.2.0 Production on RedHat AS 5.5 x86_64 and saw some problems in 31lob.t. Here are the issues: [uuuuuuuu@xxxxxxxxx DBD-Oracle-1.28]$ prove -b -v t/31lob.t t/31lob.t .. 1..12 ok 1 - returned valid locator ok 2 - inserted into BLOB successfully ok 3 - got back what we put in ok 4 - returned valid locator ok 5 - returned valid locator ok 6 - returned initialized locator ok 7 - returned length ok 8 - returned written value not ok 9 - returned length via PL/SQL # Failed test 'returned length via PL/SQL' # at t/31lob.t line 152. # got: undef # expected: '40000' Errors in file : OCI-21500: internal error code, arguments: [kghufree_06], [0x01E724258], [0], [0], [0], [], [], [] Ð 4Ð 4Ð 4ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿm¤YÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜV²+ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜV²+ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜV²+`o¤Y`o¤Y`o¤Y`o¤Y`o¤Y`o¤Y`o¤Y`o¤YErrors in file : OCI-21500: internal error code, arguments: [kghufree_06], [0x01E724258], [0], [0], [0], [], [], [] Ð 4Ð 4Ð 4ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿo¤YÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜV²+ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜV²+ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜV²+Pq¤YPq¤YPq¤YPq¤YPq¤YPq¤YPq¤YPq¤Y Dubious, test returned 1 (wstat 256, 0x100) Failed 4/12 subtests Test Summary Report ------------------- t/31lob.t (Wstat: 256 Tests: 9 Failed: 1) Failed test: 9 Non-zero exit status: 1 Parse errors: Bad plan. You planned 12 tests but ran 9. Files=1, Tests=9, 0 wallclock secs ( 0.03 usr 0.02 sys + 0.07 cusr 0.09 csys = 0.21 CPU) Result: FAIL Wes --- Wes Brown ewb4@alumni.cwru.edu wes@smellycat.com http://web.smellycat.com/wes/About.me.html KB8TGR
Download (untitled) / with headers
text/plain 500b
On Thu Jul 07 20:34:27 2011, wes@smellycat.com wrote: Show quoted text
> $ perl5 -v > > This is perl 5, version 12, subversion 3 (v5.12.3) built for x86_64- > linux-thread-multi > > Very similar to ID: 69305
Yup, looks like it. If possible, can you try to run the tests against v1.28 of DBD::Oracle? I'm curious to see if that's a new bug, or it's something that has been around and is bubbling up for 11g (it should be the former, but getting confirmation would be nice). Thanks for the bug report! `/anick
CC: Wes Brown <wes [...] smellycat.com>
Subject: Re: [rt.cpan.org #69350] Issue in 31lob.t for DBD::Oracle 1.28
Date: Fri, 8 Jul 2011 23:11:34 -0400
To: Pythian Remote DBA via RT <bug-DBD-Oracle [...] rt.cpan.org>
From: Wes Brown <wes [...] smellycat.com>
Download (untitled) / with headers
text/plain 1017b
On Fri, Jul 08, 2011 at 09:47:56AM -0400, Pythian Remote DBA via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=69350 > > > On Thu Jul 07 20:34:27 2011, wes@smellycat.com wrote:
> > $ perl5 -v > > > > This is perl 5, version 12, subversion 3 (v5.12.3) built for x86_64- > > linux-thread-multi > > > > Very similar to ID: 69305
> > Yup, looks like it. > > If possible, can you try to run the tests against v1.28 of DBD::Oracle? > I'm curious to see if that's a new bug, or it's something that has been > around and is bubbling up for 11g (it should be the former, but getting > confirmation would be nice). > > Thanks for the bug report! > `/anick
I shall work with the correct folks to get access to one of our Oracle 11 databases as well as do the same build using our Oracle 11 Client install. I will report the other three tests back so it can assist. 11.2 Client -> 10.2 Database (Done) 10.2 Client -> 10.2 Database 11.2 Client -> 11.2 Database 10.2 Client -> 11.2 Database Thanks Wes
Subject: Re: [rt.cpan.org #69350] Issue in 31lob.t for DBD::Oracle 1.28
Date: Mon, 11 Jul 2011 09:55:57 -0400
To: Pythian Remote DBA via RT <bug-DBD-Oracle [...] rt.cpan.org>
From: Wes Brown <wes [...] smellycat.com>
Download (untitled) / with headers
text/plain 4.3k
Show quoted text
> I shall work with the correct folks to get access to one of our Oracle 11 > databases as well as do the same build using our Oracle 11 Client install. > I will report the other three tests back so it can assist. > > 11.2 Client -> 10.2 Database (Done) > 10.2 Client -> 10.2 Database > 11.2 Client -> 11.2 Database > 10.2 Client -> 11.2 Database > > Thanks > > Wes
As requested, I have attached tests from Oracle 10 clients as well. It appears that those are working without issue. Let me know how I can assist in any further testing. I will have access to both of these databases for as long as necessary. Wes 10.2 Client -> 11.2 Database Oracle 10.2.0.5.0 Client to Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production $ prove -b -v t/31lob.t t/31lob.t .. 1..12 ok 1 - returned valid locator ok 2 - inserted into BLOB successfully ok 3 - got back what we put in ok 4 - returned valid locator ok 5 - returned valid locator ok 6 - returned initialized locator ok 7 - returned length ok 8 - returned written value ok 9 - returned length via PL/SQL ok 10 - returned LOB as string ok 11 - returned IN/OUT LOB as string ok 12 # skip can't check num of temp lobs, no access to v$session ok All tests successful. Files=1, Tests=12, 1 wallclock secs ( 0.03 usr 0.04 sys + 0.11 cusr 0.04 csys = 0.22 CPU) Result: PASS 11.2 Client -> 11.2 Database Oracle 11.2.0.2.0 Client to Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production $ prove -b -v t/31lob.t t/31lob.t .. 1..12 ok 1 - returned valid locator ok 2 - inserted into BLOB successfully ok 3 - got back what we put in ok 4 - returned valid locator ok 5 - returned valid locator ok 6 - returned initialized locator ok 7 - returned length ok 8 - returned written value not ok 9 - returned length via PL/SQL # Failed test 'returned length via PL/SQL' # at t/31lob.t line 152. # got: undef # expected: '40000' Errors in file : OCI-21500: internal error code, arguments: [kghufree_06], [0x0058F6258], [0], [0], [0], [], [], [] Ð 4Ð 4Ð 4ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿHÊjÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜ&®*ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜ&®*ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜ&®*àIÊjàIÊjàIÊjàIÊjàIÊjàIÊjàIÊjàIÊjErrors in file : OCI-21500: internal error code, arguments: [kghufree_06], [0x0058F6258], [0], [0], [0], [], [], [] Ð 4Ð 4Ð 4ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜ&®*ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜ&®*ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÜ&®*ÐKÊjÐKÊjÐKÊjÐKÊjÐKÊjÐKÊjÐKÊjÐKÊj Dubious, test returned 1 (wstat 256, 0x100) Failed 4/12 subtests Test Summary Report ------------------- t/31lob.t (Wstat: 256 Tests: 9 Failed: 1) Failed test: 9 Non-zero exit status: 1 Parse errors: Bad plan. You planned 12 tests but ran 9. Files=1, Tests=9, 1 wallclock secs ( 0.03 usr 0.00 sys + 0.12 cusr 0.03 csys = 0.18 CPU) Result: FAIL 10.2 Client -> 11.2 Database Oracle 10.2.0.5.0 Client to Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production $ prove -b -v t/31lob.t t/31lob.t .. 1..12 ok 1 - returned valid locator ok 2 - inserted into BLOB successfully ok 3 - got back what we put in ok 4 - returned valid locator ok 5 - returned valid locator ok 6 - returned initialized locator ok 7 - returned length ok 8 - returned written value ok 9 - returned length via PL/SQL ok 10 - returned LOB as string ok 11 - returned IN/OUT LOB as string ok 12 # skip can't check num of temp lobs, no access to v$session ok All tests successful. Files=1, Tests=12, 4 wallclock secs ( 0.04 usr 0.02 sys + 0.11 cusr 0.05 csys = 0.22 CPU) Result: PASS
Subject: Re: [rt.cpan.org #69350] Issue in 31lob.t for DBD::Oracle 1.28
Date: Tue, 12 Jul 2011 10:44:45 -0400
To: bug-DBD-Oracle [...] rt.cpan.org
From: Yanick Champoux <champoux [...] pythian.com>
Download (untitled) / with headers
text/plain 581b
On 07/11/11 09:56, Wes Brown via RT wrote: Show quoted text
> As requested, I have attached tests from Oracle 10 clients as well. It > appears that those are working without issue. Let me know how I can > assist in any further testing. I will have access to both of these > databases for as long as necessary.
Many thanks. That's going to be useful for the hunt of what looks like an ugly cross-version problem. *put on OCI goggles and XS-diving gears* This is going to be fun, I can feel it... Joy, `/anick -- The best compliment you could give Pythian for our service is a referral.
Download (untitled) / with headers
text/plain 310b
Wes, If you could run a failing example with ora_verbose set high (6 I think) and attach the output it might help someone identify the issue. Just change 31lob.t so the connect call adds ora_verbose => 6 after that PrintError => 0 and rerun the test with prove -vb. Martin -- Martin J. Evans Wetherby, UK
CC: Wes Brown <wes [...] smellycat.com>
Subject: Re: [rt.cpan.org #69350] Issue in 31lob.t for DBD::Oracle 1.28
Date: Wed, 13 Jul 2011 17:24:46 -0400
To: Martin J Evans via RT <bug-DBD-Oracle [...] rt.cpan.org>
From: Wes Brown <wes [...] smellycat.com>
Download (untitled) / with headers
text/plain 38.5k

Message body is not shown because it is too large.

Download (untitled) / with headers
text/plain 844b
Hmmm... Darn. The 11.2g client/server combination is working on my machine: $ prove -v -b t/00versions.t t/31lob.t t/00versions.t .. 1..2 # OCI client library version: 11.2.0.1 ok 1 # database version: Oracle Database 11g Release 11.2.0.2.0 - 64bit Production ok 2 ok t/31lob.t ....... 1..12 ok 1 - returned valid locator ok 2 - inserted into BLOB successfully ok 3 - got back what we put in ok 4 - returned valid locator ok 5 - returned valid locator ok 6 - returned initialized locator ok 7 - returned length ok 8 - returned written value ok 9 - returned length via PL/SQL ok 10 - returned LOB as string ok 11 - returned IN/OUT LOB as string ok 12 - no temp lobs left ok All tests successful. Files=2, Tests=14, 2 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr 0.07 csys = 0.25 CPU) Result: PASS
Subject: Re: [rt.cpan.org #69350] Issue in 31lob.t for DBD::Oracle 1.28
Date: Wed, 3 Aug 2011 13:11:52 -0400
To: Pythian Remote DBA via RT <bug-DBD-Oracle [...] rt.cpan.org>
From: Wes Brown <wes [...] smellycat.com>
Download (untitled) / with headers
text/plain 1.2k
On Wed, Jul 27, 2011 at 02:27:31PM -0400, Pythian Remote DBA via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=69350 > > > Hmmm... Darn. The 11.2g client/server combination is working on my machine: > > $ prove -v -b t/00versions.t t/31lob.t > t/00versions.t .. > 1..2 > # OCI client library version: 11.2.0.1 > ok 1 > # database version: Oracle Database 11g Release 11.2.0.2.0 - 64bit > Production > ok 2 > ok > t/31lob.t ....... > 1..12 > ok 1 - returned valid locator > ok 2 - inserted into BLOB successfully > ok 3 - got back what we put in > ok 4 - returned valid locator > ok 5 - returned valid locator > ok 6 - returned initialized locator > ok 7 - returned length > ok 8 - returned written value > ok 9 - returned length via PL/SQL > ok 10 - returned LOB as string > ok 11 - returned IN/OUT LOB as string > ok 12 - no temp lobs left > ok > All tests successful. > Files=2, Tests=14, 2 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr > 0.07 csys = 0.25 CPU) > Result: PASS
Is it possible that it is something that crept in at Oracle Client version 11.2.0.2.x? This is about the only thing that is different that I can see from my less than expert point of observation. Thanks Wes
Download (untitled) / with headers
text/plain 243b
Gwen was able to reproduce the problem, and confirmed that the issue is not a new one for 1.29_1, but is present to all releases since 1.24. In light of that, I'm going ahead with the release of 1.30 (and will try to squash this bug for 1.32).
Download (untitled) / with headers
text/plain 505b
On Fri Aug 26 15:35:23 2011, PYTHIAN wrote: Show quoted text
> Gwen was able to reproduce the problem, and confirmed that the issue is > not a new one for 1.29_1, but is present to all releases since 1.24. In > light of that, I'm going ahead with the release of 1.30 (and will try to > squash this bug for 1.32).
I don't understand why 31lob.t now says: plan skip_all => "see RT#69350" if ORA_OCI() =~ /^11\.2\./; I have 11.2 and if I uncomment the above the test runs fine. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #69350] Issue in 31lob.t for DBD::Oracle 1.28
Date: Mon, 05 Mar 2012 13:17:39 -0500
To: bug-DBD-Oracle [...] rt.cpan.org
From: Yanick Champoux <champoux [...] pythian.com>
Download (untitled) / with headers
text/plain 887b
On 03/03/12 06:07, Martin J Evans via RT wrote: Show quoted text
> I don't understand why 31lob.t now says: > > plan skip_all => "see RT#69350" > if ORA_OCI() =~ /^11\.2\./; > > I have 11.2 and if I uncomment the above the test runs fine.
Yes, if you look at the previous comments, some installations with 11.2 do have successful test runs. It, however, appears that there are some instances that do die in the middle of the test file. It would be more logical to use a TODO wrapper in there instead of a skip_all, but the general idea is not to have random installations fail because of that test, until we can figure out what is the core problem. `/anick -- Yanick Champoux, Senior Perl Developer The Pythian Group - love your data http://www.pythian.com -- -- Pythian proud winner of Oracle North America Titan Award for Exadata Solution...watch the video on pythian.com
Download (untitled) / with headers
text/plain 1.6k
On Mon Mar 05 13:17:51 2012, PYTHIAN wrote: Show quoted text
> On 03/03/12 06:07, Martin J Evans via RT wrote:
> > I don't understand why 31lob.t now says: > > > > plan skip_all => "see RT#69350" > > if ORA_OCI() =~ /^11\.2\./; > > > > I have 11.2 and if I uncomment the above the test runs fine.
> > Yes, if you look at the previous comments, some installations with > 11.2 do have successful test runs. It, however, appears that there are > some instances that do die in the middle of the test file. > > It would be more logical to use a TODO wrapper in there instead of > a skip_all, but the general idea is not to have random installations > fail because of that test, until we can figure out what is the core
problem. Wouldn't it make more sense to run the test whatever, as in fact, there is a problem. If I had this issue with my 11.2 I'd want to know I've probably got a issue with lobs rather than just skip it then find lobs fail later in my code. In DBD::ODBC there are a number of drivers I've found with bugs and I've wrestled with whether to leave the test failing or to catch the failure and issue a warning but not fail the test. Where there is a workaround I've always done the latter and where there isn't I always did the former but then I got loads of people reporting a test error I already knew about so I changed it to no fail and issue a warning. I think it is better to run the test, catch the issue and warn the user they could have problems with lobs. It is also more likely to lead to a fix from Oracle as the issue looks like an oracle one. I would have reported it to Oracle but as I've never seen it myself I cannot do that. Martin -- Martin J. Evans Wetherby, UK
Download (untitled) / with headers
text/plain 261b
31lob.t fails for me with Perl 5.12.3 and Oracle 11.1.07. I'm not sure how long it's been failing (presumably since 1.28 but I'm not positive). I've attached the output of prove -vb t/31lob.t with ora_verbose => 6 (sanitizied to remove db username/password).
Subject: 31lob failed.txt
Download 31lob failed.txt
text/plain 54k

Message body is not shown because it is too large.

Download (untitled) / with headers
text/plain 798b
On Mon Mar 26 14:12:11 2012, MMUSGROVE wrote: Show quoted text
> 31lob.t fails for me with Perl 5.12.3 and Oracle 11.1.07. I'm not sure > how long it's been failing (presumably since 1.28 but I'm not positive). > > I've attached the output of prove -vb t/31lob.t with ora_verbose => 6 > (sanitizied to remove db username/password). >
I really don't know what to do with this RT. It is failing in OCIDescriptorFree with an internal Oracle error and I cannot find that error listed in Oracle bug fixes. I cannot personally report issues to Oracle so I'm stuck. Changing to stalled for now. I still think it would be best not to skip this test but run it and capture the problem outputting a warning if found then at least the people with this issue will know to avoid it. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #69350] Issue in 31lob.t for DBD::Oracle 1.28
Date: Sun, 24 Jun 2012 16:54:08 -0400
To: Martin J Evans via RT <bug-DBD-Oracle [...] rt.cpan.org>
From: Wes Brown <wes [...] smellycat.com>
Download (untitled) / with headers
text/plain 1.2k
On Sun, Jun 24, 2012 at 05:15:26AM -0400, Martin J Evans via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=69350 > > > On Mon Mar 26 14:12:11 2012, MMUSGROVE wrote:
> > 31lob.t fails for me with Perl 5.12.3 and Oracle 11.1.07. I'm not sure > > how long it's been failing (presumably since 1.28 but I'm not positive). > > > > I've attached the output of prove -vb t/31lob.t with ora_verbose => 6 > > (sanitizied to remove db username/password). > >
> > I really don't know what to do with this RT. It is failing in > OCIDescriptorFree with an internal Oracle error and I cannot find that > error listed in Oracle bug fixes. I cannot personally report issues to > Oracle so I'm stuck. > > Changing to stalled for now. > > I still think it would be best not to skip this test but run it and > capture the problem outputting a warning if found then at least the > people with this issue will know to avoid it. > > Martin > -- > Martin J. Evans > Wetherby, UK
I am willing to attempt to report the bug to Oracle, but I am not sure how exactly to go about that. Let me know if that is something that should be tried. I think I can open this as something that is impacting the business that I work for. It just may be a challenge to get visibility to this at the Oracle level. Thanks Wes
Download (untitled) / with headers
text/plain 2.2k
On Sun Jun 24 16:54:25 2012, wes@smellycat.com wrote: Show quoted text
> On Sun, Jun 24, 2012 at 05:15:26AM -0400, Martin J Evans via RT wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=69350 > > > > > On Mon Mar 26 14:12:11 2012, MMUSGROVE wrote:
> > > 31lob.t fails for me with Perl 5.12.3 and Oracle 11.1.07. I'm not sure > > > how long it's been failing (presumably since 1.28 but I'm not
positive). Show quoted text
> > > > > > I've attached the output of prove -vb t/31lob.t with ora_verbose => 6 > > > (sanitizied to remove db username/password). > > >
> > > > I really don't know what to do with this RT. It is failing in > > OCIDescriptorFree with an internal Oracle error and I cannot find that > > error listed in Oracle bug fixes. I cannot personally report issues to > > Oracle so I'm stuck. > > > > Changing to stalled for now. > > > > I still think it would be best not to skip this test but run it and > > capture the problem outputting a warning if found then at least the > > people with this issue will know to avoid it. > > > > Martin > > -- > > Martin J. Evans > > Wetherby, UK
> > I am willing to attempt to report the bug to Oracle, but I am not sure how > exactly to go about that. Let me know if that is something that should > be tried. I think I can open this as something that is impacting the > business that I work for. It just may be a challenge to get visibility to > this at the Oracle level. > > Thanks > > Wes
Thanks for coming back on this one Wes. To give some background, I'm trying very hard to clean up the RT queue. Had the issue you found been one I could reproduce I might have had some chance but in any case it ends on an Oracle internal error. I cannot report this to Oracle as I don't personally have access to Oracle support. What you do boils down to what matters to you as this is only a test case and I would assume you do not hit the situation for real. If you choose to report it I would imagine the script and the log output (you posted previously) would be sufficient for Oracle (along with various versions etc). As it appears you are the only one to hit this there seems little greater good in getting it sorted. That leaves us with the dilemma of what to do with the RT but that is our problem. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #69350] Issue in 31lob.t for DBD::Oracle 1.28
Date: Mon, 25 Jun 2012 20:56:42 -0400
To: Martin J Evans via RT <bug-DBD-Oracle [...] rt.cpan.org>
From: Wes Brown <wes [...] smellycat.com>
Download (untitled) / with headers
text/plain 3.6k
On Mon, Jun 25, 2012 at 01:24:33PM -0400, Martin J Evans via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=69350 > > > On Sun Jun 24 16:54:25 2012, wes@smellycat.com wrote:
> > On Sun, Jun 24, 2012 at 05:15:26AM -0400, Martin J Evans via RT wrote:
> > > <URL: https://rt.cpan.org/Ticket/Display.html?id=69350 > > > > > > > On Mon Mar 26 14:12:11 2012, MMUSGROVE wrote:
> > > > 31lob.t fails for me with Perl 5.12.3 and Oracle 11.1.07. I'm not sure > > > > how long it's been failing (presumably since 1.28 but I'm not
> positive).
> > > > > > > > I've attached the output of prove -vb t/31lob.t with ora_verbose => 6 > > > > (sanitizied to remove db username/password). > > > >
> > > > > > I really don't know what to do with this RT. It is failing in > > > OCIDescriptorFree with an internal Oracle error and I cannot find that > > > error listed in Oracle bug fixes. I cannot personally report issues to > > > Oracle so I'm stuck. > > > > > > Changing to stalled for now. > > > > > > I still think it would be best not to skip this test but run it and > > > capture the problem outputting a warning if found then at least the > > > people with this issue will know to avoid it. > > > > > > Martin > > > -- > > > Martin J. Evans > > > Wetherby, UK
> > > > I am willing to attempt to report the bug to Oracle, but I am not sure how > > exactly to go about that. Let me know if that is something that should > > be tried. I think I can open this as something that is impacting the > > business that I work for. It just may be a challenge to get visibility to > > this at the Oracle level. > > > > Thanks > > > > Wes
> > Thanks for coming back on this one Wes. To give some background, I'm > trying very hard to clean up the RT queue. Had the issue you found been > one I could reproduce I might have had some chance but in any case it > ends on an Oracle internal error. > > I cannot report this to Oracle as I don't personally have access to > Oracle support. What you do boils down to what matters to you as this is > only a test case and I would assume you do not hit the situation for > real. If you choose to report it I would imagine the script and the log > output (you posted previously) would be sufficient for Oracle (along > with various versions etc). > > As it appears you are the only one to hit this there seems little > greater good in getting it sorted. That leaves us with the dilemma of > what to do with the RT but that is our problem. > > Martin > -- > Martin J. Evans > Wetherby, UK
I would like to do everything that I can to assist in helping you resolve this test failure. To be honest, the amount that I know about Oracle can be captured in a small container. I ran across this problem as part of the tests run after the module build. I do also seem to recall that someone was able to reproduce the problem, but I know that you were not able to. Might it have something to do with permissions? I asked our DBA to create the account I used to test with as few permissions as possible. As it has been some time since the first occurance of this, I would like to try to rebuild things with the latest version of Oracle 11 as well as the latest version of the DBD. I do not believe that will occur this month, but I can try to do that in July. Might you be able to provide a code to English translation of the test that was running and where you saw it blow up from the trace I was able to provide? I will also review this with my DBA to see if there is some obscure permission that I need to have to do the operation that the system is not happy about. Thanks for your work on this DBD. I can honestly say we use it every day with our Oracle 10.x client connecting to databases as old as 8.1.7. Wes
From: mcdave [...] stanford.edu
On Mon Jun 25 13:24:32 2012, MJEVANS wrote: Show quoted text
> I cannot report this to Oracle as I don't personally have access to > Oracle support. What you do boils down to what matters to you as this is > only a test case and I would assume you do not hit the situation for > real. If you choose to report it I would imagine the script and the log > output (you posted previously) would be sufficient for Oracle (along > with various versions etc). > > As it appears you are the only one to hit this there seems little > greater good in getting it sorted. That leaves us with the dilemma of > what to do with the RT but that is our problem. > > Martin
I came across this issue today while trying to set up a brand new server. It has Oracle Instantclient version 11.2, connecting back to an Oracle 11.1.0.6.0 database. I used DBD::Oracle version 1.36. I edited 31lob.t to remove the "skip" statement and to add "ora_verbose => 6" as recommended above. I've attached the results of "prove -vb t/31lob.t" (after editing out my ORACLE_USERID values). I can try filing a service ticket with Oracle and see what comes of that.
Subject: 31lob_tkt69350.txt
Download 31lob_tkt69350.txt
text/plain 34.9k

Message body is not shown because it is too large.

Download (untitled) / with headers
text/plain 1.6k
On Thu Jul 12 13:31:33 2012, mcdave@stanford.edu wrote: Show quoted text
> On Mon Jun 25 13:24:32 2012, MJEVANS wrote:
> > I cannot report this to Oracle as I don't personally have access to > > Oracle support. What you do boils down to what matters to you as this is > > only a test case and I would assume you do not hit the situation for > > real. If you choose to report it I would imagine the script and the log > > output (you posted previously) would be sufficient for Oracle (along > > with various versions etc). > > > > As it appears you are the only one to hit this there seems little > > greater good in getting it sorted. That leaves us with the dilemma of > > what to do with the RT but that is our problem. > > > > Martin
> > I came across this issue today while trying to set up a brand new > server. It has Oracle Instantclient version 11.2, connecting back to an > Oracle 11.1.0.6.0 database. I used DBD::Oracle version 1.36. I edited > 31lob.t to remove the "skip" statement and to add "ora_verbose => 6" as > recommended above. I've attached the results of "prove -vb t/31lob.t" > (after editing out my ORACLE_USERID values). > > I can try filing a service ticket with Oracle and see what comes of that.
You log shows a similar result which is again an internal error. I'm not saying DBD::Oracle's use of OCI is flawless but whatever, I'd not expect an internal error. If you can file a ticket and you are happy to do so I'd be very interested in the outcome and I will help in whatever way I can. You can use my CPAN email address mjevans@cpan.org and I can be found on #dbi on irc.perl.org. Thanks Martin -- Martin J. Evans Wetherby, UK
Just attaching a log from Win64 with OIC 11.2.
Subject: 31lob.log
Download 31lob.log
application/octet-stream 30.1k

Message body not shown because it is not plain text.

From: rmd+bcrd [...] sanger.ac.uk
Download (untitled) / with headers
text/plain 1.1k
On Thu Jul 12 13:42:20 2012, MJEVANS wrote: Show quoted text
> You log shows a similar result which is again an internal error. I'm not > saying DBD::Oracle's use of OCI is flawless but whatever, I'd not expect > an internal error. If you can file a ticket and you are happy to do so > I'd be very interested in the outcome and I will help in whatever way I > can. You can use my CPAN email address mjevans@cpan.org and I can be > found on #dbi on irc.perl.org.
I just came across this bug while attempting to build DBD::Oracle 1.52, and may have found a solution. The attached patch for t/31lob.t fixes it for me. I have tested it on various versions of perl, and against both the full and instant 11.2 clients. The trigger appears to be at line 127 in t/31lob.t, where reusing $sth causes the LOB in $loc to be destroyed before it gets bound as input in line 129. This makes the test fail, and also seems to lead to a double free later on when everything is being tidied up. Using a new statement handle for this query means $loc still contains a valid LOB, the test works and the internal error goes away. I have attached before and after log files for you to compare. Rob.
From: rmd+bcrd [...] sanger.ac.uk
Download (untitled) / with headers
text/plain 149b
On Tue Nov 13 13:24:22 2012, rob1999 wrote: Show quoted text
> The attached patch for t/31lob.t ....
Grrr. My attachments didn't. I will try again, sorry. Rob.
Subject: 31lob.t.patch.txt
Download 31lob.t.patch.txt
text/plain 752b
--- DBD-Oracle-1.52/t/31lob.t 2012-10-19 16:41:17.000000000 +0100 +++ DBD-Oracle-1.52.patch/t/31lob.t 2012-11-12 13:35:56.000000000 +0000 @@ -124,10 +124,10 @@ my $plsql_testcount = 4; $stmt = "BEGIN ? := DBMS_LOB.GETLENGTH( ? ); END;"; - $sth = $dbh->prepare( $stmt, { ora_auto_lob => 0 } ); - $sth->bind_param_inout( 1, \$len, 16 ); - $sth->bind_param( 2, $loc, { ora_type => ORA_BLOB } ); - $sth->execute; + my $sth2 = $dbh->prepare( $stmt, { ora_auto_lob => 0 } ); + $sth2->bind_param_inout( 1, \$len, 16 ); + $sth2->bind_param( 2, $loc, { ora_type => ORA_BLOB } ); + $sth2->execute; # ORA-00600: internal error code # ORA-00900: invalid SQL statement
Subject: 31lob_patched.log
Download 31lob_patched.log
text/x-log 212.5k

Message body is not shown because it is too large.

Subject: 31lob_orig.log
Download 31lob_orig.log
text/x-log 73.3k

Message body is not shown because it is too large.

Download (untitled) / with headers
text/plain 1.5k
On Tue Nov 13 13:24:22 2012, rob1999 wrote: Show quoted text
> On Thu Jul 12 13:42:20 2012, MJEVANS wrote: >
> > You log shows a similar result which is again an internal error. I'm not > > saying DBD::Oracle's use of OCI is flawless but whatever, I'd not expect > > an internal error. If you can file a ticket and you are happy to do so > > I'd be very interested in the outcome and I will help in whatever way I > > can. You can use my CPAN email address mjevans@cpan.org and I can be > > found on #dbi on irc.perl.org.
> > I just came across this bug while attempting to build DBD::Oracle > 1.52, and may have found a solution. The attached patch for t/31lob.t > fixes it for me. I have tested it on various versions of perl, and > against both the full and instant 11.2 clients. > > The trigger appears to be at line 127 in t/31lob.t, where reusing $sth > causes the LOB in $loc to be destroyed before it gets bound as input in > line 129. This makes the test fail, and also seems to lead to a double > free later on when everything is being tidied up. Using a new statement > handle for this query means $loc still contains a valid LOB, the test > works and the internal error goes away. > > I have attached before and after log files for you to compare. > > Rob. > >
Thanks Rob. I've never been able to reproduce this. Your patch seems pretty straight forward but it would be nice to understand what is happening. I'll take a look at it as soon as I can and apply it once I understand what is going on. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #69350] Issue in 31lob.t for DBD::Oracle 1.28
Date: Mon, 26 Nov 2012 14:13:37 -0500
To: bug-DBD-Oracle [...] rt.cpan.org
From: Yanick Champoux <champoux [...] pythian.com>
Download (untitled) / with headers
text/plain 561b
On 12-11-15 02:19 PM, Martin J Evans via RT wrote: Show quoted text
> Your patch seems pretty straight forward but it would be nice to > understand what is happening. I'll take a look at it as soon as I can > and apply it once I understand what is going on.
I've committed an even simpler version of the patch to trunk. But yeah, it'd still be nice to know why in this case the $lob is not surviving the deallocation of its parent $sth. Cheers, `/anick -- Yanick Champoux, Senior Perl Developer The Pythian Group - love your data http://www.pythian.com -- --
Download (untitled) / with headers
text/plain 1.8k
On Mon Nov 26 14:13:54 2012, PYTHIAN wrote: Show quoted text
> On 12-11-15 02:19 PM, Martin J Evans via RT wrote:
> > Your patch seems pretty straight forward but it would be nice to > > understand what is happening. I'll take a look at it as soon as I can > > and apply it once I understand what is going on.
> > I've committed an even simpler version of the patch to trunk. But > yeah, it'd still be nice to know why in this case the $lob is not > surviving the deallocation of its parent $sth. > > Cheers, > `/anick >
Yanick. Your change seemed to be: Modified: dbd-oracle/trunk/t/31lob.t ============================================================================== --- dbd-oracle/trunk/t/31lob.t (original) +++ dbd-oracle/trunk/t/31lob.t Mon Nov 26 11:09:03 2012 @@ -123,8 +123,10 @@ ## test calling PL/SQL with LOB placeholder my $plsql_testcount = 4; - $stmt = "BEGIN ? := DBMS_LOB.GETLENGTH( ? ); END;"; - $sth = $dbh->prepare( $stmt, { ora_auto_lob => 0 } ); + my $sth = $dbh->prepare( + 'BEGIN ? := DBMS_LOB.GETLENGTH( ? ); END;', + { ora_auto_lob => 0 } + ); $sth->bind_param_inout( 1, \$len, 16 ); $sth->bind_param( 2, $loc, { ora_type => ORA_BLOB } ); $sth->execute; I don't think this has the same result as Rob's patch. Lines numbers after your patch: The problem is that $loc is a lob locator associated with the statement $sth created a line 94. By reassigning $sth to a new prepared statement at line 126 the original $sth is thrown away and the $loc is no longer valid. Rob's change got around that by ensuring the second statement was a new scalar thus not destroying the original $sth with the lob locator. Now that Rob has pointed this out it makes sense. I think his patch is a proper fix. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #69350] Issue in 31lob.t for DBD::Oracle 1.28
Date: Tue, 27 Nov 2012 10:52:26 -0500
To: bug-DBD-Oracle [...] rt.cpan.org
From: Yanick Champoux <champoux [...] pythian.com>
Download (untitled) / with headers
text/plain 432b
On 12-11-27 05:27 AM, Martin J Evans via RT wrote: Show quoted text
> I don't think this has the same result as Rob's patch.
I think it does. :-) The patch doesn't reassign $sth, it creates a new lexical variable of the same name in the inner block that eclipses the original variable, but otherwise leaves it untouched. Try it! my $foo = "hello world"; { my $foo = "buh-bye"; } print $foo; -- --
Download (untitled) / with headers
text/plain 282b
On Tue Nov 27 10:52:46 2012, PYTHIAN wrote: Show quoted text
> On 12-11-27 05:27 AM, Martin J Evans via RT wrote:
> > I don't think this has the same result as Rob's patch.
> > I think it does. :-)
OOPs. Me having a bad day. Sorry, I missed the "my". Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #69350] Issue in 31lob.t for DBD::Oracle 1.28
Date: Tue, 27 Nov 2012 11:20:24 -0500
To: bug-DBD-Oracle [...] rt.cpan.org
From: Yanick Champoux <champoux [...] pythian.com>
Download (untitled) / with headers
text/plain 368b
On 12-11-27 11:02 AM, Martin J Evans via RT wrote: Show quoted text
>>> > >I don't think this has the same result as Rob's patch.
>> > >> > I think it does.:-)
> OOPs. Me having a bad day. > > Sorry, I missed the "my".
Heh. No problem. It's still good to have a second pair of eyes, because God knows I also have my share of derping days. :-) Cheers, `/anick -- --
deployed.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.