Incorrect method shown in stack trace #14356

p5pRT · 2014-12-22T19:10:24Z

Migrated from rt.perl.org#123480 (status was 'open')

Searchable as RT123480$

p5pRT · 2014-12-22T19:10:24Z

From @frioux

Created by @frioux

I think that for some reason a method is getting incorrectly named in a
stacktrace. It may be an incorrect line number, but I am pretty sure it's not a
simple off by one, because if you put a bunch of misc lines (print statements
eg) between the call to FetchRow and the call to Finish you still see the line
number being the end of the block. The following script should be able to
reproduce it:

use 5.20.1;
use warnings;
my $DataLoop = My::DBIODBC->new;
$DataLoop->Prepare('SELECT * FROM "Setup"');
$DataLoop->Execute;

while ($DataLoop->FetchRow) {
$DataLoop->Finish;
}

BEGIN {
package My::DBIODBC;

use warnings;
use strict;
use DBI;

sub new {
my ($class) = @_;

my $self = {};

$self->{DBI_DBH} = DBI->connect(
# "dbi:ODBC:server=10.6.6.17;port=1433;database=Lynx;driver=SQL Server Native Client 11.0;uid=sa;pwd=Password1!"
"dbi:Pg:database=postgres;host=127.0.0.1;port=5432;user=postgres;password=postgres;"
);
bless $self;
}

sub FetchRow {
my $self = shift;

if (my $sth = $self->{DBI_STH}) {
my @row = $sth->fetchrow_array;
$self->{DBI_ROW} = \@row;

return 1 if @row;
}
return undef;
}

sub Finish {
my $self = shift;
my $sth = $self->{DBI_STH};
$sth->finish()
if $self->{DBI_SQL_STATMENT};
}

sub Prepare {
my $self = shift;
my $SQL_statment = shift;

$self->{DBI_SQL_STATMENT} = $SQL_statment;

my $dbh = $self->{DBI_DBH};

my $sth = $dbh->prepare_cached($SQL_statment, {}, 1);

return if $self->{DBI_STH} = $sth;
1;
}

sub Execute {
my $self = shift;
my $param;
my @values = @_;

my $sth = $self->{DBI_STH};

$sth->execute(@values) if $sth;

$self->{DBI_ERR} = $DBI::err;
$self->{DBI_ERRSTR} = $DBI::errstr;

die "->Sql($self->{DBI_SQL_STATMENT}) Error= Error($DBI::err) : $DBI::errstr"
if $DBI::err;

$self->{DBI_NAME} = $sth->{NAME} if $sth;

return ($self->{DBI_ERR}) ? 1 : undef;

}

1;
}

I get the following as the output when I run with Carp::Always:

$ perl -MCarp::Always ~/bar.pl
DBD::Pg::st fetchrow_array failed: no statement executing at /home/frew/bar.pl line 34.
My::DBIODBC::FetchRow(My::DBIODBC=HASH(0x2552370)) called at /home/frew/bar.pl line 8

Perl Info


Flags:
    category=core
    severity=medium

Site configuration information for perl 5.20.1:

Configured by frew at Mon Sep 15 08:20:25 CDT 2014.

Summary of my perl5 (revision 5 version 20 subversion 1) configuration:
   
  Platform:
    osname=linux, osvers=3.13.0-34-generic, archname=x86_64-linux
    uname='linux tungsten 3.13.0-34-generic #60-ubuntu smp wed aug 13 15:45:27 utc 2014 x86_64 x86_64 x86_64 gnulinux '
    config_args='-Dprefix=/home/frew/.plenv/versions/5.20.1 -de -Dusedevel -A'eval:scriptdir=/home/frew/.plenv/versions/5.20.1/bin''
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.8.2', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
    libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.19'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'



@INC for perl 5.20.1:
    /home/frew/.plenv/versions/5.20.1/lib/perl5/site_perl/5.20.1/x86_64-linux
    /home/frew/.plenv/versions/5.20.1/lib/perl5/site_perl/5.20.1
    /home/frew/.plenv/versions/5.20.1/lib/perl5/5.20.1/x86_64-linux
    /home/frew/.plenv/versions/5.20.1/lib/perl5/5.20.1
    .


Environment for perl 5.20.1:
    HOME=/home/frew
    LANG=en_US.UTF-8
    LANGUAGE=en_US:en
    LD_LIBRARY_PATH=/opt/lib:/home/frew/Dropbox/instantclient_12_1
    LOGDIR (unset)
    PATH=/home/frew/.plenv/versions/5.20.1/bin:/home/frew/.plenv/libexec:/home/frew/.plenv/plugins/perl-build/bin:/home/frew/.plenv/bin:/home/frew/node/bin:/home/frew/code/git-super-status/bin:/opt/bin:/home/frew/code/teatime/bin:/home/frew/bin:/home/frew/neovim/bin:/home/frew/code/dotfiles/bin:/home/frew/code/dotfiles/git-hub/lib:/home/frew/Sync/bin:/home/frew/Dropbox/bin:/home/frew/Dropbox/node/bin:/opt/bin:/home/frew/go/bin:/home/frew/.rakudobrew/bin:/home/frew/.plenv/bin:/home/frew/node/bin:/home/frew/code/git-super-status/bin:/opt/bin:/home/frew/code/teatime/bin:/home/frew/bin:/home/frew/code/dotfiles/bin:/home/frew/code/dotfiles/git-hub/lib:/home/frew/Sync/bin:/home/frew/Dropbox/bin:/home/frew/Dropbox/node/bin:/home/frew/go/bin:/home/frew/.plenv/shims:/home/frew/perl5/perlbrew/bin:/home/frew/perl5/perlbrew/perls/perl-5.16.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/frew/.zsh/adenosine/bin:/home/frew/.zsh/adenosine/bin
    PERL_BADLANG (unset)
    SHELL=/bin/zsh

p5pRT · 2014-12-22T23:28:26Z

From @jkeenan

On Mon Dec 22 11:10:24 2014, frew@cpan.org wrote:

This is a bug report for perl from frew@cpan.org,
generated with the help of perlbug 1.40 running under perl 5.20.1.

-----------------------------------------------------------------
[Please describe your issue here]

I think that for some reason a method is getting incorrectly named in
a
stacktrace. It may be an incorrect line number, but I am pretty sure
it's not a
simple off by one, because if you put a bunch of misc lines (print
statements
eg) between the call to FetchRow and the call to Finish you still see
the line
number being the end of the block. The following script should be
able to
reproduce it:

use 5.20.1;
use warnings;
my $DataLoop = My::DBIODBC->new;
$DataLoop->Prepare('SELECT * FROM "Setup"');
$DataLoop->Execute;

while ($DataLoop->FetchRow) {
$DataLoop->Finish;
}

BEGIN {
package My::DBIODBC;

use warnings;
use strict;
use DBI;

sub new {
my ($class) = @_;

my $self = {};

$self->{DBI_DBH} = DBI->connect(
# "dbi:ODBC:server=10.6.6.17;port=1433;database=Lynx;driver=SQL
Server Native Client 11.0;uid=sa;pwd=Password1!"
"dbi:Pg:database=postgres;host=127.0.0.1;port=5432;user=postgres;password=postgres;"
);
bless $self;
}

sub FetchRow {
my $self = shift;

if (my $sth = $self->{DBI_STH}) {
my @row = $sth->fetchrow_array;
$self->{DBI_ROW} = \@row;

return 1 if @row;
}
return undef;
}

sub Finish {
my $self = shift;
my $sth = $self->{DBI_STH};
$sth->finish()
if $self->{DBI_SQL_STATMENT};
}

sub Prepare {
my $self = shift;
my $SQL_statment = shift;

$self->{DBI_SQL_STATMENT} = $SQL_statment;

my $dbh = $self->{DBI_DBH};

my $sth = $dbh->prepare_cached($SQL_statment, {}, 1);

return if $self->{DBI_STH} = $sth;
1;
}

sub Execute {
my $self = shift;
my $param;
my @values = @_;

my $sth = $self->{DBI_STH};

$sth->execute(@values) if $sth;

$self->{DBI_ERR} = $DBI::err;
$self->{DBI_ERRSTR} = $DBI::errstr;

die "->Sql($self->{DBI_SQL_STATMENT}) Error= Error($DBI::err) :
$DBI::errstr"
if $DBI::err;

$self->{DBI_NAME} = $sth->{NAME} if $sth;

return ($self->{DBI_ERR}) ? 1 : undef;

}

1;
}

I get the following as the output when I run with Carp::Always:

$ perl -MCarp::Always ~/bar.pl
DBD::Pg::st fetchrow_array failed: no statement executing at
/home/frew/bar.pl line 34.
My::DBIODBC::FetchRow(My::DBIODBC=HASH(0x2552370)) called at
/home/frew/bar.pl line 8

Can you comment on why you believe this is a problem with the Perl 5 core distribution rather than with one of the modules in your example?

Also, can you be a bit more specific about which method is getting misnamed?

Thank you very much.

--
James E Keenan (jkeenan@cpan.org)

p5pRT · 2014-12-22T23:28:26Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2014-12-23T14:31:22Z

From frioux@gmail.com

On Mon, Dec 22, 2014 at 03:28:26PM -0800, James E Keenan via RT wrote:

Can you comment on why you believe this is a problem with the Perl 5 core distribution rather than with one of the modules in your example?

Not really no. Initially I thought it was a DBI problem, but Tim
Bunce seemed confident that it is a core issue on IRC. I don't know
enough to be able to prove that.

Also, can you be a bit more specific about which method is getting misnamed?

In the printed stack trace the final line is

My::DBIODBC::FetchRow(My::DBIODBC=HASH(0x2552370)) called at /home/frew/bar.pl line 8

Yet line 8 is actually

$DataLoop->Finish;

So for some reason the call to ->Finish consistently gets reported as
a call to FetchRow.

--
fREW Schmidt
https://blog.afoolishmanifesto.com

p5pRT · 2014-12-23T14:57:14Z

From @demerphq

On 23 December 2014 at 15:30, fREW Schmidt <frioux@gmail.com> wrote:

On Mon, Dec 22, 2014 at 03:28:26PM -0800, James E Keenan via RT wrote:

Can you comment on why you believe this is a problem with the Perl 5 core distribution rather than with one of the modules in your example?

Not really no. Initially I thought it was a DBI problem, but Tim
Bunce seemed confident that it is a core issue on IRC. I don't know
enough to be able to prove that.

Also, can you be a bit more specific about which method is getting misnamed?

In the printed stack trace the final line is
   My&#8203;::DBIODBC&#8203;::FetchRow$My&#8203;::DBIODBC=HASH\(0x2552370$\) called at /home/frew/bar\.pl line 8
Yet line 8 is actually
   $DataLoop\->Finish;
So for some reason the call to ->Finish consistently gets reported as
a call to FetchRow.

FetchRow() is called in the while condition. This is an old issue with
perl, that it misreports the line number of certain errors that occur
in places like if/elseifs, and things like this. ISTR it has something
to do with us not attaching line number data to every op.

I suspect this is in the "hard-to-fix/wont-fix" category.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2014-12-23T15:04:16Z

From frioux@gmail.com

On Tue, Dec 23, 2014 at 06:57:14AM -0800, yves orton via RT wrote:

FetchRow() is called in the while condition. This is an old issue with
perl, that it misreports the line number of certain errors that occur
in places like if/elseifs, and things like this. ISTR it has something
to do with us not attaching line number data to every op.

I suspect this is in the "hard-to-fix/wont-fix" category.

Yves

Ok! Not a huge deal to me, I was worried it was a 5.20 regression
because I hadn't noticed before.

--
fREW Schmidt
https://blog.afoolishmanifesto.com

p5pRT added Severity Medium distro-Linux type-core labels Oct 19, 2019

xenu removed the affects-5.20 label Nov 19, 2021

xenu removed the Severity Medium label Dec 15, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Incorrect method shown in stack trace #14356

Incorrect method shown in stack trace #14356

p5pRT commented Dec 22, 2014

p5pRT commented Dec 22, 2014

p5pRT commented Dec 22, 2014

p5pRT commented Dec 22, 2014

p5pRT commented Dec 23, 2014

p5pRT commented Dec 23, 2014

p5pRT commented Dec 23, 2014

Incorrect method shown in stack trace #14356

Incorrect method shown in stack trace #14356

Comments

p5pRT commented Dec 22, 2014

p5pRT commented Dec 22, 2014

From @frioux

Created by @frioux

p5pRT commented Dec 22, 2014

From @jkeenan

p5pRT commented Dec 22, 2014

p5pRT commented Dec 23, 2014

From frioux@gmail.com

p5pRT commented Dec 23, 2014

From @demerphq

p5pRT commented Dec 23, 2014

From frioux@gmail.com