Core dump caused by goto #9104

p5pRT · 2007-11-07T16:23:31Z

Migrated from rt.perl.org#47233 (status was 'resolved')

Searchable as RT47233$

p5pRT · 2007-11-07T16:23:32Z

From @jdhedden

Created by @jdhedden

Given the following code (attached):

#!/usr/bin/perl

use strict;
use warnings;

{
no warnings 'redefine';

my $isa = \&UNIVERSAL::isa;

*UNIVERSAL::isa = sub
{
print("Jumping to original isa\n"); # Comment me out
goto $isa;
};
}

MAIN:
{
my $obj = bless({}, 'SomeClass');
print((UNIVERSAL::isa($obj, undef))
? 'is is not ok'
: 'is not is ok', "\n");
}

Under 5.10.0, the above produces:

Jumping to original isa
Segmentation fault (core dumped)

Commenting out the designated print statement produces:

Use of uninitialized value $isa in goto at ./bug.pl line 21.
is not is ok

Correspondingly, under 5.8.8 it produces:

Jumping to original isa
Use of uninitialized value in goto at bug.pl line 14.
is not is ok

and

Use of uninitialized value in goto at bug.pl line 14.
is not is ok

The above shows that the goto is actually working, but the
warning (and core dump) indicate a Perl bug.

I use the above mechanism in my module Object::InsideOut.
Having recently added tests similar to the above, its test
suite produces the following eroneous warnings:

Use of uninitialized value within @cc in goto at t/15-type.t line 121.

Use of uninitialized value in subroutine entry at
/usr/local/src/perl/mine/OIO/blib/lib/Object/InsideOut/Universal.pm
line 174.

Perl Info


Flags:
    category=core
    severity=critical

Site configuration information for perl 5.10.0:

Configured by Jerry at Tue Nov  6 13:18:11 EST 2007.

Summary of my perl5 (revision 5 version 10 subversion 0 patch 32227)
configuration:
  Platform:
    osname=cygwin, osvers=1.5.24(0.15642), archname=cygwin-thread-multi-64int
    uname='cygwin_nt-5.1 pn100-02-2-356p 1.5.24(0.15642) 2007-01-31
10:57 i686 cygwin '
    config_args='-de -Dusedevel -Dversiononly=no -Dinstallusrbinperl
-DPERL_OLD_COPY_ON_WRITE -Duse64bitint -Dusethreads -Uusemymalloc
-Dnoextensions=attrs IPC/SysV Sys/Syslog DB_File NDBM_File ODBM_File
SDBM_File Devel/DProf Devel/Peek re Text/Soundex Math/BigInt/FastCalc
Time/Piece -A append:ccflags= -DPL_OP_SLAB_ALLOC -DNO_MATHOMS -A
define:optimize=-Os -pipe -funit-at-a-time -march=pentium4
-mfpmath=sse -mieee-fp -mmmx -msse -msse2'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
-DPL_OP_SLAB_ALLOC -DNO_MATHOMS -fno-strict-aliasing -pipe',
    optimize='-Os -pipe -funit-at-a-time -march=pentium4 -mfpmath=sse
-mieee-fp -mmmx -msse -msse2',
    cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
-DPL_OP_SLAB_ALLOC -DNO_MATHOMS -fno-strict-aliasing -pipe'
    ccversion='', gccversion='3.4.4 (cygming special, gdc 0.12, using
dmd 0.125)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='g++', ldflags =' -Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--stack,8388608
-Wl,--enable-auto-image-base -Wl,--enable-auto-import -s
-L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib /lib
    libs=-lgdbm -ldl -lcrypt -lgdbm_compat
    perllibs=-ldl -lcrypt -lgdbm_compat
    libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
    cccdlflags=' ', lddlflags=' --shared  -Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--stack,8388608
-Wl,--enable-auto-image-base -Wl,--enable-auto-import -s
-L/usr/local/lib'

Locally applied patches:
    DEVEL


@INC for perl 5.10.0:
    /usr/lib/perl5/5.10.0/cygwin
    /usr/lib/perl5/5.10.0
    .


Environment for perl 5.10.0:
    CYGWIN=ntsec
    HOME=/home/jhedden
    LANG=C
    LANGUAGE=C
    LC_ALL=C
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/jhedden/bin:/usr/local/src/perl/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/c/Program
Files/WiX:/c/djgpp/bin:/c/Program
Files/apache-ant-1.7.0/bin:/c/Program
Files/nant-0.85/bin:/c/j2sdk1.4.2_14/bin:/c/dev-cpp/bin/:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/system32/WBEM:/c/blp/API/dde:/c/blp/API:/c/oracle/ora92/bin:/c/Program
Files/Oracle/jre/1.3.1/bin:/c/Program
Files/Oracle/jre/1.1.8/bin:/c/Program
Files/Hummingbird/Connectivity/7.10/Accessories/:.
    PERLIO=perlio
    PERL_BADLANG (unset)
    SHELL (unset)

p5pRT · 2007-11-07T16:23:32Z

From @jdhedden

goto_bug.pl

p5pRT · 2007-11-07T19:00:05Z

From @jdhedden

This bug is also evoked with the following (attached):

#!/usr/bin/perl

use strict;
use warnings;

sub isa
{
goto \&UNIVERSAL::isa;
}

isa({}, undef);

Under 5.10.0, this produces:

Use of uninitialized value in goto at ./goto_bug2.pl line 11.

Commenting out 'use warnings' suppresses the warning.
Changing undef to 'foo' also eliminates the warning.

p5pRT · 2007-11-07T19:00:05Z

From @jdhedden

goto_bug2.pl

p5pRT · 2007-11-07T19:14:58Z

From maddingue@free.fr

Jerry D. Hedden wrote:

This bug is also evoked with the following (attached):
\#\!/usr/bin/perl

use strict;
use warnings;

sub isa
\{
    goto \\&UNIVERSAL&#8203;::isa;
\}

isa$\{\}\, undef$;
Under 5.10.0, this produces:
Use of uninitialized value in goto at \./goto\_bug2\.pl line 11\.
Commenting out 'use warnings' suppresses the warning.
Changing undef to 'foo' also eliminates the warning.

But this warning also happens with previous versions of Perl, so it's
not new, and in this case probably normal:

$ /usr/local/perl/5.8.8/bin/perl -wMstrict -e 'sub isa { goto \&UNIVERSAL::isa }
isa({}, undef)'
Use of uninitialized value in goto at -e line 1.

$ /usr/local/perl/5.6.2/bin/perl -wMstrict -e 'sub isa { goto \&UNIVERSAL::isa }
isa({}, undef)'
Use of uninitialized value in goto at -e line 1.

$ /usr/local/perl/5.4.5/bin/perl -wMstrict -e 'sub isa { goto \&UNIVERSAL::isa }
isa({}, undef)'
Use of uninitialized value at -e line 1.

--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

p5pRT · 2007-11-07T19:14:58Z

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

p5pRT · 2007-11-07T19:19:07Z

From @nwc10

On Wed, Nov 07, 2007 at 08:23:32AM -0800, Jerry D. Hedden wrote:

Given the following code (attached):

\#\!/usr/bin/perl

use strict;
use warnings;

\{
    no warnings 'redefine';

    my $isa = \\&UNIVERSAL&#8203;::isa;

    \*UNIVERSAL&#8203;::isa = sub
    \{
        print\("Jumping to original isa\\n"\);  \# Comment me out
        goto $isa;
    \};
\}

MAIN&#8203;:
\{
    my $obj = bless\(\{\}\, 'SomeClass'\);
    print\(\(UNIVERSAL&#8203;::isa\($obj\, undef\)\)
                ? 'is is not ok'
                : 'is not is ok'\, "\\n"\);
\}

Under 5.10.0, the above produces:

Jumping to original isa
Segmentation fault \(core dumped\)

==19376==
Jumping to original isa
==19376== Invalid read of size 4
==19376== at 0x8171F56: S_varname (sv.c:11808)
==19376== by 0x81729F6: S_find_uninit_var (sv.c:11915)
==19376== by 0x81742CB: S_find_uninit_var (sv.c:12135)
==19376== by 0x817436E: Perl_report_uninit (sv.c:12165)
==19376== by 0x8137887: Perl_sv_2pv_flags (sv.c:2754)
==19376== by 0x824B8B5: XS_UNIVERSAL_isa (universal.c:310)
==19376== by 0x81C80C8: Perl_pp_goto (pp_ctl.c:2403)
==19376== by 0x80C5E73: Perl_runops_debug (dump.c:1931)
==19376== by 0x81039EE: S_run_body (perl.c:2384)
==19376== by 0x8102E53: perl_run (perl.c:2302)
==19376== by 0x80606A1: main (perlmain.c:113)
==19376== Address 0x0 is not stack'd, malloc'd or (recently) free'd

else {
CV * const cv = find_runcv(NULL);
SV *sv;
AV *av;

if (!cv || !CvPADLIST(cv))
return NULL;
av = (AV*)(*av_fetch(CvPADLIST(cv), 0, FALSE));
sv = *av_fetch(av, targ, FALSE);
sv_setpvn(name, SvPV_nolen_const(sv), SvCUR(sv));
}

Line 11808 is sv = *av_fetch(av, targ, FALSE);

I assume that it's returning NULL, but I don't want to blindly patch it as

a: why is this the first time where it's returned NULL?
b: should the previous av_fetch be checked? [or all of them]
c: what is the correct response to getting NULL?

This is just about the SEGV. I don't know about the unitialised warning
itself.

Nicholas Clark

p5pRT · 2007-11-07T19:22:33Z

From @jdhedden

Jerry D. Hedden wrote:

This bug is also evoked with the following (attached):
\#\!/usr/bin/perl

use strict;
use warnings;

sub isa
\{
    goto \\&UNIVERSAL&#8203;::isa;
\}

isa$\{\}\, undef$;
Under 5.10.0, this produces:
Use of uninitialized value in goto at \./goto\_bug2\.pl line 11\.
Commenting out 'use warnings' suppresses the warning.
Changing undef to 'foo' also eliminates the warning.

Sébastien Aperghis-Tramoniwrote:

But this warning also happens with previous versions of Perl, so it's
not new, and in this case probably normal:

$ /usr/local/perl/5.8.8/bin/perl -wMstrict -e 'sub isa { goto \&UNIVERSAL::isa }
isa({}, undef)'
Use of uninitialized value in goto at -e line 1.

$ /usr/local/perl/5.6.2/bin/perl -wMstrict -e 'sub isa { goto \&UNIVERSAL::isa }
isa({}, undef)'
Use of uninitialized value in goto at -e line 1.

$ /usr/local/perl/5.4.5/bin/perl -wMstrict -e 'sub isa { goto \&UNIVERSAL::isa }
isa({}, undef)'
Use of uninitialized value at -e line 1.

I'll grant you that the bug is not new to 5.10.0. However,
as reported in previous message, it can be made to core dump
in 5.10.0, and erroneously complains about unassociated
variables. So the bug appears to have been exacerbated.

What do you mean by 'in this case probably normal'?
"Normal" would denote proper or expected. IMHO, it is
neither - it's a bug.

p5pRT · 2007-11-07T19:34:56Z

From @jdhedden

Jerry D. Hedden wrote:

I use the above mechanism in my module Object::InsideOut.
Having recently added tests similar to the above, its test
suite produces the following eroneous warnings:
Use of uninitialized value within @&#8203;cc in goto at t/15\-type\.t line 121\.

The following (attached) evokes the above:

#!/usr/bin/perl

use strict;
use warnings;

{
no warnings 'redefine';

my @foo = ();

my $isa = \&UNIVERSAL::isa;

*UNIVERSAL::isa = sub
{
goto $isa;
};
}

UNIVERSAL::isa({}, undef);

Under 5.10.0, it produces:

Use of uninitialized value @foo in goto at goto_bug3.pl line 19.

Under 5.8.8, it produces:

Use of uninitialized value in goto at goto_bug3.pl line 15.

p5pRT · 2007-11-07T19:34:56Z

From @jdhedden

goto_bug3.pl

p5pRT · 2007-11-08T00:16:19Z

From @iabyn

On Wed, Nov 07, 2007 at 07:18:01PM +0000, Nicholas Clark wrote:

On Wed, Nov 07, 2007 at 08:23:32AM -0800, Jerry D. Hedden wrote:
Given the following code (attached):
\#\!/usr/bin/perl

use strict;
use warnings;

\{
    no warnings 'redefine';

    my $isa = \\&UNIVERSAL&#8203;::isa;

    \*UNIVERSAL&#8203;::isa = sub
    \{
        print$"Jumping to original isa\\n"$;  \# Comment me out
        goto $isa;
    \};
\}

MAIN&#8203;:
\{
    my $obj = bless$\{\}\, 'SomeClass'$;
    print$\(UNIVERSAL&#8203;::isa\($obj\, undef$\)
                ? 'is is not ok'
                : 'is not is ok'\, "\\n"\);
\}
Under 5.10.0, the above produces:
Jumping to original isa
Segmentation fault $core dumped$
==19376==
Jumping to original isa
==19376== Invalid read of size 4
==19376== at 0x8171F56: S_varname (sv.c:11808)

Hmm, what is happening is that the "use of uninit" warning occurs within
the XS code of UNIVERSAL::isa. IT turns out that XS code called via goto
has the call stack and pad of the parent, ie in

MAIN: {
sub f { goto &some::XS::sub }
f();
}

The XS code sees the pad and CV of PL_main_cv rather than that of
f() or some::XS::sub().

This causes the guessing code to go around poking into the wrong pads,
with badness and coredumps to follow.

I will have to think about how to deal with this.
I suspect there's also a similar issue with a normal (pp_entersub) calls
to XS code.

It's too late to ponder now, will worry about it another day.

This is just about the SEGV. I don't know about the unitialised warning
itself.

Isn't this just because the second arg to isa() is undef???

--
Hofstadter's Law: It always takes longer than you expect, even when you
take into account Hofstadter's Law.

p5pRT · 2007-11-08T00:28:12Z

From @jdhedden

This is just about the SEGV. I don't know about the unitialised warning
itself.

Isn't this just because the second arg to isa() is undef???

I don't think so. The following is doesn't produce any
warnings, and does not seg fault:

perl -e 'my $x; UNIVERSAL::isa(\$x, undef)'

However, the following:

perl -we 'my $x; UNIVERSAL::isa(\$x, undef)'

produces:

Use of uninitialized value in subroutine entry at -e line 1.

p5pRT · 2007-11-08T00:41:13Z

From chromatic@wgz.org

On Wednesday 07 November 2007 16:27:41 Jerry D. Hedden wrote:

I don't think so. The following is doesn't produce any
warnings, and does not seg fault:
perl \-e 'my $x; UNIVERSAL&#8203;::isa$\\$x\, undef$'
However, the following:
perl \-we 'my $x; UNIVERSAL&#8203;::isa$\\$x\, undef$'
produces:
Use of uninitialized value in subroutine entry at \-e line 1\.

You appear to have proven that not enabling warnings disables the undef
warning. There may be an additional point in this example too subtle for me
to understand though.

-- c

p5pRT · 2007-11-08T01:02:35Z

From @jdhedden

Jerry D. Hedden wrote:

I don't think so. The following is doesn't produce any
warnings, and does not seg fault:
perl \-e 'my $x; UNIVERSAL&#8203;::isa$\\$x\, undef$'
However, the following:
perl \-we 'my $x; UNIVERSAL&#8203;::isa$\\$x\, undef$'
produces:
Use of uninitialized value in subroutine entry at \-e line 1\.

chromatic wrote:

You appear to have proven that not enabling warnings disables the undef
warning. There may be an additional point in this example too subtle for me
to understand though.

Sorry, I guess I cut off too much from the previous message.
The question was whether or not the undef was causing a seg
vault, and I demonstrated this was not the case.

I added the part about the warning because it seemed
inappropriate: Passing undef to a subroutine should be
okay.

p5pRT · 2007-11-08T01:51:23Z

From @iabyn

On Wed, Nov 07, 2007 at 07:27:41PM -0500, Jerry D. Hedden wrote:

This is just about the SEGV. I don't know about the unitialised warning
itself.

Isn't this just because the second arg to isa() is undef???

I don't think so. The following is doesn't produce any
warnings, and does not seg fault:
perl \-e 'my $x; UNIVERSAL&#8203;::isa$\\$x\, undef$'
However, the following:
perl \-we 'my $x; UNIVERSAL&#8203;::isa$\\$x\, undef$'
produces:
Use of uninitialized value in subroutine entry at \-e line 1\.

I don't follow you at all. Ignoring for the moment the segfault, which I
have already admitted to be a bug (;-), your two examples seem to show
that if you

a) enable warnings

and

b) pass an uninitialised value,

you, err, get an uninitialised value warning.

What's buggy about that ????

--
"Strange women lying in ponds distributing swords is no basis for a system
of government. Supreme executive power derives from a mandate from the
masses, not from some farcical aquatic ceremony."
-- Dennis, "Monty Python and the Holy Grail"

p5pRT · 2007-11-08T01:52:39Z

From @iabyn

On Wed, Nov 07, 2007 at 08:02:09PM -0500, Jerry D. Hedden wrote:

Jerry D. Hedden wrote:
I don't think so. The following is doesn't produce any
warnings, and does not seg fault:
perl \-e 'my $x; UNIVERSAL&#8203;::isa$\\$x\, undef$'
However, the following:
perl \-we 'my $x; UNIVERSAL&#8203;::isa$\\$x\, undef$'
produces:
Use of uninitialized value in subroutine entry at \-e line 1\.
chromatic wrote:

You appear to have proven that not enabling warnings disables the undef
warning. There may be an additional point in this example too subtle for me
to understand though.

Sorry, I guess I cut off too much from the previous message.
The question was whether or not the undef was causing a seg
vault, and I demonstrated this was not the case.

The undef value generates a warning. Due to a bug in the variable naming
code (ie the bit that determines XXX in "Use of uninitialized value
$XXX"), printing the warning will sometimes cause a segfault, depending on
pad alignments etc.

Are we now agreed that the segfault is the only thing that's buggy?
And that the bug is in my variable naming code?

--
You never really learn to swear until you learn to drive.

p5pRT · 2007-11-08T02:50:32Z

From @jdhedden

Dave Mitchell wrote:

Are we now agreed that the segfault is the only thing that's buggy?

I still don't understand why the warning is generated. The following:

#!/usr/bin/perl

use strict;
use warnings;

my $x;
UNIVERSAL::isa(\$x, undef);

produces:

Use of uninitialized value in subroutine entry at ./bug2.pl line 7.

However, this doesn't produce any warnings:

#!/usr/bin/perl

use strict;
use warnings;

sub test {
my ($thing, $class) = @_;
return;
}

my $x;
test(\$x, undef);

Passing undef to a subroutine is permitted. Why does passing undef to
UNIVERSAL::isa produce a warning? It seems to me that this is a bug.

p5pRT · 2007-11-08T02:54:23Z

From @tonycoz

On Wed, Nov 07, 2007 at 09:48:07PM -0500, Jerry D. Hedden wrote:

Passing undef to a subroutine is permitted. Why does passing undef to
UNIVERSAL::isa produce a warning? It seems to me that this is a bug.

UNIVERSAL::isa() uses the values you supply to it. If your test()
attempted to print the value, it would warn too.

Since UNIVERSAL::isa() is XS the undef warning is displayed for the
calling context.

Tony

p5pRT · 2007-11-08T15:35:53Z

From @jdhedden

Jerry D. Hedden wrote:

Passing undef to a subroutine is permitted. Why does passing undef to
UNIVERSAL::isa produce a warning? It seems to me that this is a bug.

Here's more "proof" of this bug. This:

perl -we 'my $x; UNIVERSAL::isa(\$x, undef)'

produces:

Use of uninitialized value in subroutine entry at -e line 1.

However, this:

perl -we 'UNIVERSAL::isa(undef, "foo")'

and this:

perl -we 'UNIVERSAL::isa(undef, undef)'

don't produce any warnings.

My conclusion is that the warning:

Use of uninitialized value in subroutine entry at -e line 1.

is not criticizing the use of undef in the subroutine call,
but is being generated erroneously.

With all of this so far, I've encountered the following
'bugs':

1. Warning referencing bogus variable:

Use of uninitialized value @foo in goto ...

2. Warning about subroutine entry:

Use of uninitialized value in subroutine entry ...

3. Seg fault

Whether or not these are all separate bugs, or two bugs (1
and 2 possibly being from the same cause), or just one bug,
I cannot say. Any any rate, I'm hoping Dave can track
them/it down and squash them/it.

p5pRT · 2007-11-08T15:45:45Z

From zefram@fysh.org

Jerry D. Hedden wrote:

My conclusion is that the warning:

Use of uninitialized value in subroutine entry at -e line 1.

is not criticizing the use of undef in the subroutine call,

Yes.

but is being generated erroneously.

No.

It's not an error to pass undef to a subroutine, in general. It *is*
an error to pass undef as the second argument to UNIVERSAL::isa().

-zefram

p5pRT · 2007-11-08T16:08:44Z

From @jdhedden

Zefram wrote:

Jerry D. Hedden wrote:

My conclusion is that the warning:

Use of uninitialized value in subroutine entry at -e line 1.

is not criticizing the use of undef in the subroutine call,

Yes.

but is being generated erroneously.

No.

It's not an error to pass undef to a subroutine, in general. It *is*
an error to pass undef as the second argument to UNIVERSAL::isa().

Okay. Thank you all for putting up with me on this. After
more digging and testing, I determined that you are correct,
namely that the warning:
Use of uninitialized value in subroutine entry ...
is not a bug.

Looking in the code for UNIVERSAL::isa:

XS(XS_UNIVERSAL_isa)
{
dVAR;
dXSARGS;
PERL_UNUSED_ARG(cv);

if (items != 2)
Perl_croak(aTHX_ "Usage: UNIVERSAL::isa(reference, kind)");
else {
SV * const sv = ST(0);
const char *name;

SvGETMAGIC(sv);

if (!SvOK(sv) || !(SvROK(sv) || (SvPOK(sv) && SvCUR(sv))
|| (SvGMAGICAL(sv) && SvPOKp(sv) && SvCUR(sv))))
XSRETURN_UNDEF;

name = SvPV_nolen_const(ST(1));

ST(0) = boolSV(sv_derived_from(sv, name));
XSRETURN(1);
}
}

I determined that the line:

name = SvPV_nolen_const(ST(1));

is the source of the warning. (Ya learn something new every
day. :)

p5pRT · 2007-11-08T19:10:00Z

From ben@morrow.me.uk

Quoth tony@develop-help.com (Tony Cook):

On Wed, Nov 07, 2007 at 09:48:07PM -0500, Jerry D. Hedden wrote:

Passing undef to a subroutine is permitted. Why does passing undef to
UNIVERSAL::isa produce a warning? It seems to me that this is a bug.

UNIVERSAL::isa() uses the values you supply to it. If your test()
attempted to print the value, it would warn too.

Since UNIVERSAL::isa() is XS the undef warning is displayed for the
calling context.

How easy would it be to change the warning to 'use of uninitialized
value in XS code' under the appropriate circumstances? It would then not
give the impression that it is the call itself that is being warned
about.

Ben

p5pRT · 2007-11-09T01:03:03Z

From @iabyn

On Thu, Nov 08, 2007 at 12:13:05AM +0000, Dave Mitchell wrote:

Hmm, what is happening is that the "use of uninit" warning occurs within
the XS code of UNIVERSAL::isa. IT turns out that XS code called via goto
has the call stack and pad of the parent, ie in
MAIN&#8203;: \{
sub f \{ goto &some&#8203;::XS&#8203;::sub \}
f;
\}
The XS code sees the pad and CV of PL_main_cv rather than that of
f() or some::XS::sub().

This causes the guessing code to go around poking into the wrong pads,
with badness and coredumps to follow.

I will have to think about how to deal with this.
I suspect there's also a similar issue with a normal (pp_entersub) calls
to XS code.

It's too late to ponder now, will worry about it another day.

I've decided the simplest and safest approach for 5.10.0 is just to
disable printing variable names when getting an uninitialised value
warning during pp_entersub or pp_goto, eg

pre-patch:

$ ./perl -we 'my $x; $x->()'
Use of uninitialized value $x in subroutine entry at -e line 1.

post-patch:

$ ./perl -we 'my $x; $x->()'
Use of uninitialized value in subroutine entry at -e line 1.

This is just reverting to 5.8.x behaviour.

I think a proper fix would be too complex for the near-code-freeze.

--
This is a great day for France!
-- Nixon at Charles De Gaulle's funeral

Change 32247 by davem@davem-pigeon on 2007/11/09 00:56:20

[perl #47233] Core dump caused by goto
tmp disable printing of variable names caused by uninitialised
values within a pp_entersub or pp_goto

Affected files ...

... //depot/perl/sv.c#1440 edit
... //depot/perl/t/lib/warnings/9uninit#16 edit

Differences ...

==== //depot/perl/sv.c#1440 (text) ====

@@ -12091,10 +12091,18 @@

case OP_RV2SV:
case OP_CUSTOM:
- case OP_ENTERSUB:
match = 1; /* XS or custom code could trigger random warnings */
goto do_op;

+ case OP_ENTERSUB:
+ case OP_GOTO:
+ /* XXX tmp hack: these to may call an XS sub, and currently
+ XS subs don't have a SUB entry on the context stack, so CV nad
+ pad deteminaion goes wrong, and BAD things happen. So, just
+ don't try to detemine the value under those circumanstances.
+ Need a better fix at dome point. DAPM 11/2007 */
+ break;
+
case OP_POS:
/* def-ness of rval pos() is independent of the def-ness of its arg */
if ( !(obase->op_flags & OPf_MOD))

==== //depot/perl/t/lib/warnings/9uninit#16 (text) ====

@@ -1069,8 +1069,8 @@
Use of uninitialized value $g1 in splice at - line 10.
Use of uninitialized value in addition (+) at - line 10.
Use of uninitialized value $m1 in method lookup at - line 13.
-Use of uninitialized value $m1 in subroutine entry at - line 15.
-Use of uninitialized value $g1 in subroutine entry at - line 16.
+Use of uninitialized value in subroutine entry at - line 15.
+Use of uninitialized value in subroutine entry at - line 16.
Use of uninitialized value $m1 in warn at - line 18.
Use of uninitialized value $g1 in warn at - line 18.
foo at - line 18.

p5pRT · 2009-12-16T00:43:22Z

From @obra

Our behavior is once-again identical to 5.8.8. Resolving.

p5pRT · 2009-12-16T00:43:24Z

@obra - Status changed from 'open' to 'resolved'

p5pRT closed this as completed Dec 16, 2009

p5pRT added the Severity Low label Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Core dump caused by goto #9104

Core dump caused by goto #9104

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 8, 2007

p5pRT commented Nov 9, 2007

p5pRT commented Dec 16, 2009

p5pRT commented Dec 16, 2009

Core dump caused by goto #9104

Core dump caused by goto #9104

Comments

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

From @jdhedden

Created by @jdhedden

p5pRT commented Nov 7, 2007

From @jdhedden

p5pRT commented Nov 7, 2007

From @jdhedden

p5pRT commented Nov 7, 2007

From @jdhedden

p5pRT commented Nov 7, 2007

From maddingue@free.fr

p5pRT commented Nov 7, 2007

p5pRT commented Nov 7, 2007

From @nwc10

p5pRT commented Nov 7, 2007

From @jdhedden

p5pRT commented Nov 7, 2007

From @jdhedden

p5pRT commented Nov 7, 2007

From @jdhedden

p5pRT commented Nov 8, 2007

From @iabyn

p5pRT commented Nov 8, 2007

From @jdhedden

p5pRT commented Nov 8, 2007

From chromatic@wgz.org

p5pRT commented Nov 8, 2007

From @jdhedden

p5pRT commented Nov 8, 2007

From @iabyn

p5pRT commented Nov 8, 2007

From @iabyn

p5pRT commented Nov 8, 2007

From @jdhedden

p5pRT commented Nov 8, 2007

From @tonycoz

p5pRT commented Nov 8, 2007

From @jdhedden

p5pRT commented Nov 8, 2007

From zefram@fysh.org

p5pRT commented Nov 8, 2007

From @jdhedden

p5pRT commented Nov 8, 2007

From ben@morrow.me.uk

p5pRT commented Nov 9, 2007

From @iabyn

p5pRT commented Dec 16, 2009

From @obra

p5pRT commented Dec 16, 2009