On Tue, Dec 14, 2004 at 06:28:57PM -0800, Jonathan Leffler wrote:
> Sorry - here is the full trace....
It's quite different to the one you posted before - and much
more normal...
> [11] Perl_report_uninit(0xff24315c, 0xff24315c, 0x0, 0x42, 0x3700,
> 0x124400), at 0x8eb0c
> [12] Perl_sv_2pv_flags(0x31f544, 0xffbee8e0, 0x2, 0xff23c008,
> 0xffbee86c, 0x303a00), at 0x92b64
> [13] Perl_sv_2pv(0x31f544, 0xffbee8e0, 0x0, 0x34f4ae, 0x34f4ac,
> 0x0), at 0x92118
> [14] dbd_ix_st_bind_ph(0x1, 0x34d328, 0x2, 0x31f544, 0xff0a5b48,
> 0x127870), at 0xff08dcb8
> [15] dbdxst_bind_params(0x2a1760, 0x34d328, 0xe, 0x10, 0xff0a5b3c,
> 0xff116a78), at 0xff084b38
> [16] XS_DBD__Informix__st_execute(0x3014bc, 0x272268, 0x0, 0x2e9bf8,
> 0x400, 0x1272e0), at 0xff0870bc
So in your dbd_ix_st_bind_ph function you're calling sv_2pv, probably
via a macro such as SvPV(sv), on the undef value.
All you've got to do is find it. If you compile/link DBD::Informix
with the -g option the stack trace should give you the line number.
Tim.
> On Wed, 15 Dec 2004 01:00:38 +0000, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > On Tue, Dec 14, 2004 at 02:13:17PM -0800, Jonathan Leffler wrote:
> > > On Fri, 3 Dec 2004 20:54:00 +0000, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > > > On Fri, Dec 03, 2004 at 12:15:06PM -0800, Jonathan Leffler wrote:
> > > > >
> > > > > Use of uninitialized value in subroutine entry at t/t91udts.t line 97.
> > > > >
> > > > > $sth->execute(2, undef, undef, ..., undef) or stmt_fail;
> > > >
> > > > That part is fine. It's something 'deeper' that triggering the
> > > > warning. Probably in the driver. Perl says "in subroutine entry"
> > > > only because that's the last "op" that perl executed (before it
> > > > entered the DBI C-code).
> > > >
> > > > Here's a trick to nail it:
> > > > $SIG{__WARN__} = sub { dump() }; # core dump on warning
> > >
> > > OK, the core dump winds through a number of functions (recognizably
> > > Perl or C library functions), but ends up going through:
> > >
> > > ...more...
> >
> > I need to see more of the "...more..." - everything up to the point
> > where you can see the warn being triggered.
> >
> > > Perl_magic_set()
> > > Perl_newHVhv()
> > > dbd_ix_st_bind_ph() -- DBD::Informix code.
> > > dbdxst_bind_params() -- DBI code?
> > > XS_DBD__Informix__st_execute() -- Interface C code for $sth->execute()?
> > > XS_DBI_dispatch() -- DBI code
> > > Perl_magic_nextpack()
> > > Perl_fbm_instr()
> > > ...more...
> >
> > That's an odd looking stack trace. magic_nextpack is involved in
> > iterating through tied hashes, calling "FIRSTKEY" or "NEXTKEY".
> > But there's no way Perl_magic_nextpack should trigger a direct
> > DBI dispatch into execute().
> >
> > Perhaps you've "helpfully" limited the detail here. If so, please
> > don't. Give me the whole stack trace.
> >
> > (And using a perl configured with -DDEBUGGING and a DBI and
> > DBD::Informix built with that perl will give more detail,
> > like params to functions, in the stack trace.)
> >
> > > Has anything changed significantly in the binding of parameters since,
> > > say, DBI 1.14? Short guidance appreciated - I'll be investigating
> > > anyway, but help on where to look might make things easier.
> >
> > Er, DBI 1.14 is over 4 years old. It would be fair to say that much
> > has changed. Feel free to binary-chop your way through the versions
> > to isolate the first that displays the warning.
>
> OK - let's take DBI 1.00 instead then :-)
>
> I'll try and isolate the problem better too.
>
>
> --
> Jonathan Leffler <[EMAIL PROTECTED]> #include <disclaimer.h>
> Guardian of DBD::Informix - v2003.04 - http://dbi.perl.org
> "I don't suffer from insanity - I enjoy every minute of it."
