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.
