Bug 548489 - Perl-DBD-Oracle INSERT/UPDATE to BLOBs via synonym fails
Summary: Perl-DBD-Oracle INSERT/UPDATE to BLOBs via synonym fails
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server
Version: 530
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Justin Sherrill
QA Contact: Milan Zázrivec
URL: https://rhn.qa.redhat.com/network/sys...
Whiteboard: Fixed in the 5.4.0 Release - GA'd 201...
Depends On:
Blocks: sat540-blockers
TreeView+ depends on / blocked
 
Reported: 2009-12-17 15:57 UTC by Sebastian Skracic
Modified: 2010-12-19 17:36 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-28 15:03:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
A proposed patch to char buffer allocation problem (613 bytes, patch)
2009-12-17 16:18 UTC, Sebastian Skracic
no flags Details | Diff

Description Sebastian Skracic 2009-12-17 15:57:43 UTC
Description of problem:

  Perl-DBD-Oracle has a bug which prevents INSERT/UPDATEs to BLOBs to complete
successfully when used on tables accessed via SYNONYMs.

Version-Release number of selected component (if applicable):

perl-DBD-Oracle-1.23-4.el5sat.x86_64

How reproducible:

Always on x86_64, might be different on i386.


Additional info:

  This bug resurfaced again, after it has been reported and apparently fixed twice (!).  Here are the CPAN reports:

http://rt.cpan.org/Public/Bug/Display.html?id=38267
http://rt.cpan.org/Public/Bug/Display.html?id=36069

  The way the bug is fixed is suboptimal, therefore the bug crops up again in 1.23, as well as in SVN trunk.  Here's the debug output generated with DBI_TRACE=3:

                lob refetch using a synonym named=rhnActionScript for RHN.RHNACTIONSCRIPT 
                lob refetch from table RHN.RHNACTIONSCRIPT, 8 columns:
                lob refetch table col 1: 'ID' otype 2
                lob refetch table col 2: 'ACTION_ID' otype 2
                lob refetch table col 3: 'USERNAME' otype 1
                lob refetch table col 4: 'GROUPNAME' otype 1
                lob refetch table col 5: 'SCRIPT' otype 113
                lob refetch table col 6: 'TIMEOUT' otype 2
                lob refetch table col 7: 'CREATED' otype 12
                lob refetch table col 8: 'MODIFIED' otype 12
                lob refetch :script param: otype 113, matched field 'SCRIPT' by name (SCRIPT "script")
                lob refetch sql: select SCRIPT "script" from SCRIPT "script" where rowid = :rid for update

  The last line shows the incorrectly rendered SQL for LOB update.

  Further analysis shows the culprit is in incorrectly allocated char buffer used to store the fully qualified table name ("RHN.RHNACTIONSCRIPT" in this case).  The buffer is allocated within the inner scope of the if-statement block, which can be, depending on the environment (operating system, compiler used, memory pressure, etc etc), discarded after the control exits the "if" clause, rendering its content random and useless.  This is the behavior when executed on at least x86_64 system.

Comment 1 Sebastian Skracic 2009-12-17 15:58:34 UTC
Set to Urgent/Urgent because it's a *showstopper* for RHN PHX2 migration.

Comment 2 Justin Sherrill 2009-12-17 16:16:47 UTC
Was this opened against satellite intentionally?  

-Justin

Comment 3 Sebastian Skracic 2009-12-17 16:18:37 UTC
Created attachment 379034 [details]
A proposed patch to char buffer allocation problem

Comment 4 Sebastian Skracic 2009-12-17 16:19:54 UTC
(In reply to comment #2)
> Was this opened against satellite intentionally?  
> 
> -Justin  

  Yes, absolutely.  As I said, it's a *showstopper* for RHN PHX2 migration, rendering the Perl part of the RHN Hosted unusable in new environment.

Comment 5 Sebastian Skracic 2009-12-17 16:22:49 UTC
With the proposed patch above, the DBI trace shows different (and correct) output, and the LOB updates no longer fail:

                lob refetch using a synonym named=rhnActionScript for RHN.RHNACTIONSCRIPT 
                lob refetch from table RHN.RHNACTIONSCRIPT, 8 columns:
                lob refetch table col 1: 'ID' otype 2
                lob refetch table col 2: 'ACTION_ID' otype 2
                lob refetch table col 3: 'USERNAME' otype 1
                lob refetch table col 4: 'GROUPNAME' otype 1
                lob refetch table col 5: 'SCRIPT' otype 113
                lob refetch table col 6: 'TIMEOUT' otype 2
                lob refetch table col 7: 'CREATED' otype 12
                lob refetch table col 8: 'MODIFIED' otype 12
                lob refetch :script param: otype 113, matched field 'SCRIPT' by name (SCRIPT "script")
                lob refetch sql: select SCRIPT "script" from RHN.RHNACTIONSCRIPT where rowid = :rid for update

Comment 6 Justin Sherrill 2009-12-17 17:22:02 UTC
Patch applied and packages built here:

https://brewweb.devel.redhat.com/brew/taskinfo?taskID=2158395

I've done some minimal testing to ensure that the perl pages work.

Comment 7 Garik Khachikyan 2010-09-06 13:07:58 UTC
hi Justin,

as a testing scenario (for bug verification): 
do you have in mind some concrete cases or I can just take random actions on perl pages there? thanks.

Comment 8 Sebastian Skracic 2010-09-06 14:02:50 UTC
The relevant cases would be triggering the Perl code to update BLOB/CLOBs in DB.  In Hosted, it can be achieved throughout the process of Proxy activation.  I don't know whether it's true for Satellite as well.

Comment 9 Justin Sherrill 2010-09-07 12:46:17 UTC
Hey Garik,

I believe proxy activation is in java in Satellite and I honestly can't find any instances of blob manipulation in perl.   

I would activate a proxy just to test, and try a few perl pages in different areas to verify they still work.   If all that checks out, i think we're good.

-Justin

Comment 11 Milan Zázrivec 2010-10-06 15:57:15 UTC
VERIFIED w/ Satellite-5.4.0-RHEL5-re20101001.1 / perl-DBD-Oracle-1.24a-3

* the patch mentioned in the bug report has been applied & used
* .pxt pages work without any problem
* blob manipulation works ok, used following script to verify:

#!/usr/bin/perl

use DBI;
use DBD::Oracle 'SQLT_BIN';
use strict;
use warnings;

my $dbh = DBI->connect("dbi:Oracle:rhnsat", "rhnsat", "rhnsat");
$dbh->{LongReadLen} = 20*1024*1024;

my $blob = "0101" for 1 .. 1000000;
my $sql = "insert into temporary_table_syn values (?)";

my $sth = $dbh->prepare($sql);
$sth->bind_param(1, $blob, { ora_type => SQLT_BIN });
$sth->execute();

$dbh->disconnect();

Comment 12 Clifford Perry 2010-10-28 15:03:36 UTC
The 5.4.0 RHN Satellite and RHN Proxy release has occurred. This issue has been resolved with this release. 


RHEA-2010:0801 - RHN Satellite Server 5.4.0 Upgrade
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10332

RHEA-2010:0803 - RHN Tools enhancement update
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10333

RHEA-2010:0802 - RHN Proxy Server 5.4.0 bug fix update
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10334

RHEA-2010:0800 - RHN Satellite Server 5.4.0
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10335

Docs are available:

http://docs.redhat.com/docs/en-US/Red_Hat_Network_Satellite/index.html 

Regards,
Clifford

Comment 13 Jiri Kastner 2010-11-04 09:32:17 UTC
patch included and applied in spec file, pxt pages works, manipulating with blobs from synonyms works.

Comment 14 Jan Pazdziora (Red Hat) 2010-12-19 17:36:59 UTC
The patch will go to DBD::Oracle 1.28:

http://svn.perl.org/viewvc/modules?view=revision&revision=14590


Note You need to log in before you can comment on or make changes to this bug.