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: 30910
Status: resolved
Priority: 0/
Queue: DBD-Oracle

People
Owner: champoux [...] pythian.com
Requestors: bbobcik [...] gmail.com
Cc:
AdminCc:

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



Subject: DBD-Oracle crashes when trying to read empty LOB
Date: Thu, 22 Nov 2007 08:25:52 +0100
To: bug-DBD-Oracle [...] rt.cpan.org
From: "Boleslav Bobcik" <bbobcik [...] gmail.com>
Module: DBD::Oracle (version 1.19 and lower) OS: WinXP Interpreter: ActiveState Perl 5.8.8 Symptoms: When trying to retrieve LOB data, where length of LOB is 0, ora_lob_read() crashes the interpreter with invalid memory access. Cause: Looking at the debugged code, I think that the problem is at the line 312 of Oracle.xs: dest_sv = sv_2mortal(newSV(length*4)); /*LAB: crude hack that works... tim did it else where XXX */ Apparently, when length==0, the resulting dest_sv is NULL and subseqent access to it is invalid. I haven't an access to different platform than Windows, therefore I am unable to verify this behaviour in other environments. It is possible to use the following workaround, but in my opinion it's just a case of "ugly hacks escalation": $lob_size = $dbh->ora_lob_length($lob_locator); $lob = $dbh->ora_lob_read($lob_locator, 1, $lob_size+1); However I believe that the problem should be quite easy to fix (e.g. early return when length is zero). --Boleslav Bobcik bbobcik@gmail.com
Ok I am going to have a look at it and see if I can recreate your problem and if you suggested patch works
I have recreated the error with this result DBD::Oracle::db::ora_lob_read: locator is not of type OCILobLocatorPtr at lob_empty2.pl line 29.
From: pause [...] pythian.com
A little more complicated than that I can solve the problem for 1 case but then it breask for all the others (typical OCI) I will work on it some more later next week. Do you have any code SQL PERL that recreates this bug exactly Cheers
From: pause [...] pythian.com
Well after stumbling about in the dark for the past few days I stumblemd on it if you read part II Chapter 4 of the Database Application Developer's Guide - Large Objects 10g Release 1 (10.1) http://www.acs.ilstu.edu/docs/oracle/appdev.101/b10796/adlob_ta.htm if you read under the heading Setting a Persistent LOB to NULL " You may want to set a persistent LOB value to NULL upon inserting the row in cases where you do not have the LOB data at the time of the INSERT or if you want to use a SELECT statement, such as the following, to determine whether the LOB holds a NULL value: SELECT COUNT (*) FROM print_media WHERE ad_graphic IS NOT NULL; SELECT COUNT (*) FROM print_media WHERE ad_graphic IS NULL; Note that you cannot call OCI or DBMS_LOB functions on a NULL LOB, so you must then use an SQL UPDATE statement to reset the LOB column to a non-NULL (or empty) value. The point is that you cannot make a function call from the supported programmatic environments on a LOB that is NULL. These functions only work with a locator, and if the LOB column is NULL, then there is no locator in the row." So basiclly thier is nothing that OCI (DBD) can do in this case. If I return empty (or early) I would imply that the field's value would be non-NULL (or empty) not NULL LOB and that would be in error. At present DBD::Oracle will error out with the error that the field value is not OCILobLocatorPtr. I will update the POD to reflect this Therefore there is not change that needs to
Normal operaion of OCI will update POD to reflect this.