[perl #41948] Combination of tie() and loop aliasing can cause perl to crash.

# New Ticket Created by  mjcarman@mchsi.com 
# Please include the string:  [perl #41948]
# in the subject line of all future correspondence about this issue. 
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41948 >


This is a bug report for perl from mjcarman@mchsi.com,
generated with the help of perlbug 1.35 running under perl v5.8.4.


-----------------------------------------------------------------
It's possible to cause a crash in perl by using a combination of tie() and the 
implicit aliasing of loop variables. I have observed this on both v5.8.4 and 
v5.8.7. The following example reproduces the problem.

#!perl
use strict;
use warnings;

package Death;
sub TIEARRAY  { bless [], __PACKAGE__ }
sub FETCH     { { a => 1, b => 2} }
sub FETCHSIZE { 1 }

package main;

tie my @array, 'Death';

foreach my $p (@array) {
  my %h = (a => $p->{a}, b => $p->{b}); # Aaaghh!
}

__END__

The code in the example isn't useful (obviously). It's a distilled version of 
what I was doing when I encountered the problem. The important part is that 
FETCH returns a reference to a different anonymous structure each time it's 
called. 

The crash only occurs when the loop variable appears multiple times in the same 
statement, but it depends on the statement:

%h = (a => $p->{a}, b => $p->{b});    # crashes
%h = (a => $p->{a});                  # okay
print $p->{a}, ' ', $p->{b}, "\n";    # crashes
print $p->{a} . ' ' . $p->{b} . "\n"; # okay
print "$p->{a} $p->{b}\n";            # okay
printf("%s %s\n", $p->{a}, $p->{b});  # doesn't crash but $p->{a} is undefined
$p->{a}, $p->{b};                     # okay (just void context warnings)
@a = ($p->{a}, $p->{b});              # crashes
$a = ($p->{a}, $p->{b});              # okay (just void context warnings)

It isn't often that Perl grants me a peek at its juicy innards, but I caught a 
glimpse here. I've learned that when the docs say that the loop varaible is an 
implicit alias for the element of the list/array, they mean *exactly* that. The 
FETCH isn't occuring as part of the loop entry. It's happening each time the 
loop variable is used as if I had written "$array[0]" instead of "$p." That 
suprised me a little. I would have expected a more direct aliasing that didn't 
require a FETCH for each occurance.

>From here on I'm speculating, but it appears that *both* fetches are being done 
before the hash lookups. Presumably the problem is that the two occurances of $p 
have different values but the way the bytecode is organized/optimized it expects 
them (not unreasonably) to have the same value. I don't know why this results in 
a crash instead of a behavior where both lookups use the second hashref 
returned. This could lead to subtle bugs if the contents of the hashes were
supposed to be different, but that's another issue.
-----------------------------------------------------------------
---
Flags:
    category=core
    severity=low
---
Site configuration information for perl v5.8.4:

Configured by ActiveState at Tue Jun  1 11:52:09 2004.

Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
  Platform:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT  -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
    optimize='-MD -Zi -DNDEBUG -O1',
    cppflags='-DWIN32'
    ccversion='', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf  -libpath:"C:\Perl\lib\CORE"  -machine:x86'
    libpth=C:\PROGRA~1\MICROS~3\VC98\lib
    libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib msvcrt.lib
    perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib msvcrt.lib
    libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
    gnulibc_version='undef'
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf  -libpath:"C:\Perl\lib\CORE"  -machine:x86'

Locally applied patches:
    ACTIVEPERL_LOCAL_PATCHES_ENTRY
    22751 Update to Test.pm 1.25
    21540 Fix backward-compatibility issues in if.pm

---
@INC for perl v5.8.4:
    C:/Perl/lib
    C:/Perl/site/lib
    .

---
Environment for perl v5.8.4:
    HOME=U:\
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Dazel\Output Envoy\bin\;C:\Program Files\Rational\ClearCase\bin;C:\Perl\bin;C:\Mingw\bin;C:\Tools
    PERL_BADLANG (unset)
    SHELL (unset)

• [perl #41948] Combination of tie() and loop aliasing can cause perl to crash. by mjcarman @ mchsi . com
• Re: [perl #41948] Combination of tie() and loop aliasing can cause perl to crash. by Dave Mitchell
• Re: [perl #41948] Combination of tie() and loop aliasing can cause perl to crash. by David Nicol