Bug #69350 for DBD-Oracle: Issue in 31lob.t for DBD::Oracle 1.28

On Thu Jul 07 20:34:27 2011, wes@smellycat.com wrote: Show quoted text
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

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. 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

On Wed, Jul 27, 2011 at 02:27:31PM -0400, Pythian Remote DBA via RT wrote: Show quoted text
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

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).

On 03/03/12 06:07, Martin J Evans via RT wrote: Show quoted text
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

On Mon, Jun 25, 2012 at 01:24:33PM -0400, Martin J Evans via RT wrote: Show quoted text
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

On Thu Jul 12 13:31:33 2012, mcdave@stanford.edu 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. Thanks Martin -- Martin J. Evans Wetherby, UK

On Thu Jul 12 13:42:20 2012, MJEVANS wrote: Show quoted text
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.

On Tue Nov 13 13:24:22 2012, rob1999 wrote: Show quoted text
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

On Mon Nov 26 14:13:54 2012, PYTHIAN wrote: Show quoted text
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

On Tue Nov 27 10:52:46 2012, PYTHIAN wrote: Show quoted text
OOPs. Me having a bad day. Sorry, I missed the "my". Martin -- Martin J. Evans Wetherby, UK

deployed.