On Thu, Feb 13, 2003 at 12:36:04AM +1100, Bradley Baetz wrote:
> On Wed, Feb 12, 2003 at 12:52:25PM +0000, Tim Bunce wrote:
> > On Wed, Feb 12, 2003 at 10:57:29PM +1100, Bradley Baetz wrote:
>
> > Thanks for digging into this!
> >
> > Here's something I wrote previously that may give some ideas:
>
> Hmm. In what context was this written? :)
See attached email.
> > > Something is causing the perl internal PL_tainted variable to
> > > get set before the fetchrow_hashref code in DBI.xs reaches the line:
> > > ka_rv = newSVsv(ka_rv); /* copy to invoke FETCH magic */
> > >
> > > If you're handy with a C debugger then run the t/10examp.t script
> > > under both the perl debugger and C debugger. Stop before that
> > > test using the perl debugger and put a watchpoint on the perl
> > > internal PL_tainted variable using the C debugger. Then continue
> > > to see where PL_tainted gets set.
>
> Unfortunately, the perl5.005 I'm using isn't a debug build. However, I
> think I know where its coming from:
>
> if (DBIc_is(imp_sth, DBIcf_TaintOut)) {
> dTHR;
> TAINT; /* affects sv_setsv()'s called within same perl statement */
> }
The "within same perl statement" is a key point.
Try moving these two lines:
SV *ka_rv = *hv_fetch((HV*)DBIc_MY_H(imp_sth), keyattrib,strlen(keyattrib),
TRUE);
ka_rv = newSVsv(ka_rv); /* copy to invoke FETCH magic */
to the top of the function, specifically before the perl_call_method("fetch",)
I think the fetch() has called _get_fbav which has set TAINT which
sets PL_tainted=1. Now anytime an sv gets copied between now and
the next statement it'll be tainted. Somehow the 'NAME_uc' is getting
tainted.
> with a lots-of-debug-lines DBI.xs and trace level 2 set. Line 348 of
> ExampleP.pm is: $sth->_set_fbav(\@new); and the XX: before shows that
> $new[1] isn't tainted before calling that.
The problem is in fetchrow_hashref *between* the perl_call_method("fetch",)
and the newSVsv(ka_rv); /* copy to invoke FETCH magic */
Given the sensitivity to perl versions it's probably something pretty subtle.
Perhaps the whole approach needs to be changed. Maybe try switching back to
explicitly tainting in the dispatcher.
Tim.
From [EMAIL PROTECTED] Sun Dec 29 21:05:58 2002
Received: from localhost (localhost [127.0.0.1])
by dansat.data-plan.com (8.12.6/8.12.6) with ESMTP id gBTL0nbU092787
for <timbo@localhost>; Sun, 29 Dec 2002 21:05:58 GMT
(envelope-from [EMAIL PROTECTED])
Received: from pop3.mail.demon.net [194.217.242.59]
by localhost with POP3 (fetchmail-5.8.5)
for timbo@localhost (single-drop); Sun, 29 Dec 2002 21:05:58 +0000 (GMT)
Received: from punt-2.mail.demon.net by mailstore for [EMAIL PROTECTED]
id 1041094516:20:03495:182; Sat, 28 Dec 2002 16:55:16 GMT
Received: from cali-3.pobox.com ([64.71.166.116]) by punt-2.mail.demon.net
id aa2104189; 28 Dec 2002 16:55 GMT
Received: from cali-3.pobox.com (localhost.localdomain [127.0.0.1])
by cali-3.pobox.com (Postfix) with ESMTP
id 28CFC2F1CE6; Sat, 28 Dec 2002 11:55:05 -0500 (EST)
Delivered-To: [EMAIL PROTECTED]
Received: from ntardis.ee.ethz.ch (tardis.ee.ethz.ch [129.132.2.217])
by cali-3.pobox.com (Postfix) with ESMTP id 002502F1C1D
for <[EMAIL PROTECTED]>; Sat, 28 Dec 2002 11:55:04 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
by ntardis.ee.ethz.ch (Postfix) with ESMTP id 0B1F2AC
for <[EMAIL PROTECTED]>; Sat, 28 Dec 2002 17:55:01 +0100 (MET)
Received: from artclip.ch (viola.ethz.ch [129.132.89.14])
by ntardis.ee.ethz.ch (Postfix) with ESMTP id C5EF99D
for <[EMAIL PROTECTED]>; Sat, 28 Dec 2002 17:55:00 +0100 (MET)
Date: Sat, 28 Dec 2002 17:55:05 +0100
Subject: Re: Test failure with DBI 1.32 on MacOS X
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
From: Christian Schaffner <[EMAIL PROTECTED]>
To: Tim Bunce <[EMAIL PROTECTED]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
X-Mailer: Apple Mail (2.548)
X-Virus-Scanned: by AMaViS new-20020517
Status: RO
Content-Length: 2882
Lines: 82
Hi Tim
Sorry to bother you again. I was trying to fix the problem described
below. But it looks like I am not enough an expert with Perl and Perl
debugger et al. I was trying to find where this variable gets set but
was unable to do so. Now, my question is: Would you be interested in
helping me get dbi working on MacOS X again? I am doing the official
fink package for dbi:
http://fink.sourceforge.net/pdb/package.php/dbi-pm
If you are interested I could propose you the following: I give you a
temporary account on my MacOS X machine where you will have all tools
needed (I hope so) to debug the problem. How does this sound? It would
be great if you would accept. I hope it would help make your dbi a bit
more MacOS X friendly and it would certainly help the increasing number
of fink users on MacOS X a lot!
Tell me what you think,
Chris.
On Montag, Dezember 16, 2002, at 01:18 Uhr, Tim Bunce wrote:
> On Mon, Dec 16, 2002 at 08:56:26AM +0100, Christian Schaffner wrote:
>> Hi Tim
>>
>> I am the fink (http://fink.sf.net) package maintainer of the DBI perl
>> module for MacOS X. I tried to update the package to version 1.32 and
>> got the following test error:
>>
>> ...
>> t/10examp...........1..245
>> ok 1 at line 33
>>
>> ... (all ok)
>>
>> ok 102 at line 316
>> fetchrow_hashref('NAME_uc')
>> ok 103 at line 319
>> Insecure dependency in parameter 1 of DBI::st=HASH(0x203388)->FETCH
>> method call while running with -T switch at t/10examp.t line 320.
>> DBI handle cleared whilst still active.
>> dbih_clearcom (sth 0x204f58 0x10cd30, com 0x1f6510, imp
>> DBD::ExampleP::st):
>> FLAGS 0x60011: COMSET Warn TaintIn TaintOut
>> PARENT DBI::db=HASH(0x1cbb34)
>> KIDS 0 (0 Active)
>> IMP_DATA ARRAY(0x205e54)
>> NUM_OF_FIELDS 3
>> NUM_OF_PARAMS 1
>> dubious
>> Test returned status 20 (wstat 5120, 0x1400)
>> DIED. FAILED tests 104-245
>> Failed 142/245 tests, 42.04% okay
>> ...
>>
>> Could you imagine what the problem here might be?
>
> Off-hand... no. You'll have to dig into it some more yourself.
>
> Something is causing the perl internal PL_tainted variable to
> get set before the fetchrow_hashref code in DBI.xs reaches the line:
> ka_rv = newSVsv(ka_rv); /* copy to invoke FETCH magic */
>
> If you're handy with a C debugger then run the t/10examp.t script
> under bother the perl debugger and C debugger. Stop before that
> test using the perl debugger and put a watchpoint on the perl
> internal PL_tainted variable using the C debugger. Then continue
> to see where PL_tainted gets set.
>
> Alternatively sprinkle a few warn("PL_tainted=%d",PL_tainted);
> into the fetchrow_hashref code in DBI.xs.
>
>> PS: Version 1.31 work fine.
>
> I think those tests we're accidentally left disabled in that version.
> Try earlier versions (diff the t/10examp.t file to check).
>
> Tim.
