Skip Menu | will be shut down on March 1st, 2021.

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

Owner: champoux [...]
Requestors: bbobcik [...]

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 [...]
From: "Boleslav Bobcik" <bbobcik [...]>
Download (untitled) / with headers
text/plain 1018b
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
Download (untitled) / with headers
text/plain 107b
Ok I am going to have a look at it and see if I can recreate your problem and if you suggested patch works
Download (untitled) / with headers
text/plain 146b
I have recreated the error with this result DBD::Oracle::db::ora_lob_read: locator is not of type OCILobLocatorPtr at line 29.
From: pause [...]
Download (untitled) / with headers
text/plain 240b
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 [...]
Download (untitled) / with headers
text/plain 1.4k
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) 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.

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

Please report any issues with to