From @mauke

Created by @mauke

perldoc perlapi​:

  newPVOP Constructs, checks, and returns an op of any type that involves an
  embedded C-level pointer (PV). type is the opcode. flags gives the
  eight bits of "op_flags". pv supplies the C-level pointer, which
  must have been allocated using "PerlMemShared_malloc"; the memory
  will be freed when the op is destroyed.

  OP * newPVOP(I32 type, I32 flags, char *pv)

"the memory will be freed when the op is destroyed" is arguably wrong. The
default action of perl is to do nothing and leak the memory. pv is only freed
if type is one of OP_DUMP, OP_GOTO, OP_NEXT, OP_LAST, OP_REDO, OP_TRANS,
OP_TRANSR, and op_flags and op_private have the right values.

(I discovered this while trying to use newPVOP(OP_CUSTOM, 0, ptr).)

Flags:
    category=docs
    severity=low

Site configuration information for perl 5.22.1:

Configured by mauke at Tue Dec 29 15:36:05 CET 2015.

Summary of my perl5 (revision 5 version 22 subversion 1) configuration:
   
  Platform:
    osname=linux, osvers=4.2.5-1-arch, archname=i686-linux
    uname='linux simplicio 4.2.5-1-arch #1 smp preempt tue oct 27 08:28:41 cet 2015 i686 gnulinux '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion='', gccversion='5.3.0', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234, doublekind=3
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12, longdblkind=3
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/gcc/i686-pc-linux-gnu/5.3.0/include-fixed /usr/lib /lib
    libs=-lpthread -lnsl -lnm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lpthread -lnsl -lnm -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.22.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.22'
  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-strong'



@INC for perl 5.22.1:
    /home/mauke/usr/lib/perl5/site_perl/5.22.1/i686-linux
    /home/mauke/usr/lib/perl5/site_perl/5.22.1
    /home/mauke/usr/lib/perl5/5.22.1/i686-linux
    /home/mauke/usr/lib/perl5/5.22.1
    .


Environment for perl 5.22.1:
    HOME=/home/mauke
    LANG=en_US.UTF-8
    LANGUAGE=en_US
    LC_COLLATE=C
    LC_MONETARY=de_DE.UTF-8
    LC_TIME=de_DE.UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/mauke/perl5/perlbrew/bin:/home/mauke/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
    PERLBREW_BASHRC_VERSION=0.73
    PERLBREW_HOME=/home/mauke/.perlbrew
    PERLBREW_ROOT=/home/mauke/perl5/perlbrew
    PERL_BADLANG (unset)
    PERL_UNICODE=SAL
    SHELL=/bin/bash

From @iabyn

On Sat, Mar 12, 2016 at 03​:04​:16PM -0800, l.mai@​web.de wrote​:

# New Ticket Created by l.mai@​web.de
# Please include the string​: [perl #127697]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=127697 >

This is a bug report for perl from l.mai@​web.de,
generated with the help of perlbug 1.40 running under perl 5.22.1.

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

perldoc perlapi​:

newPVOP Constructs\, checks\, and returns an op of any type that involves an
        embedded C\-level pointer \(PV\)\. type is the opcode\. flags gives the
        eight bits of "op\_flags"\. pv supplies the C\-level pointer\, which
        must have been allocated using "PerlMemShared\_malloc"; the memory
        will be freed when the op is destroyed\.

                OP \*    newPVOP\(I32 type\, I32 flags\, char \*pv\)

"the memory will be freed when the op is destroyed" is arguably wrong. The
default action of perl is to do nothing and leak the memory. pv is only freed
if type is one of OP_DUMP, OP_GOTO, OP_NEXT, OP_LAST, OP_REDO, OP_TRANS,
OP_TRANSR, and op_flags and op_private have the right values.

I suppose the question is whether to fix the code or the docs.
I could see op_clear() doing a PerlMemShared_free(cPVOPo->op_pv)
if the op type is OP_CUSTOM and xop_class is OA_PVOP_OR_SVOP.

Having had a quick look at op_clear(), I also note that there is a latent
bug in op_pv field handling​: the OP_DUMP etc cases fall through to the
OP_TRANS cases, which check for OPpTRANS_FROM_UTF etc private flags. If
those flags should at some point in the future overlap with private flags
in OP_DUMP etc, then things will go wrong.

--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.

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

From @iabyn

On Mon, Mar 14, 2016 at 09​:33​:54AM +0000, Dave Mitchell wrote​:

On Sat, Mar 12, 2016 at 03​:04​:16PM -0800, l.mai@​web.de wrote​:

# New Ticket Created by l.mai@​web.de
# Please include the string​: [perl #127697]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=127697 >

This is a bug report for perl from l.mai@​web.de,
generated with the help of perlbug 1.40 running under perl 5.22.1.

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

perldoc perlapi​:

newPVOP Constructs\, checks\, and returns an op of any type that involves an
        embedded C\-level pointer \(PV\)\. type is the opcode\. flags gives the
        eight bits of "op\_flags"\. pv supplies the C\-level pointer\, which
        must have been allocated using "PerlMemShared\_malloc"; the memory
        will be freed when the op is destroyed\.

                OP \*    newPVOP\(I32 type\, I32 flags\, char \*pv\)

"the memory will be freed when the op is destroyed" is arguably wrong. The
default action of perl is to do nothing and leak the memory. pv is only freed
if type is one of OP_DUMP, OP_GOTO, OP_NEXT, OP_LAST, OP_REDO, OP_TRANS,
OP_TRANSR, and op_flags and op_private have the right values.

I suppose the question is whether to fix the code or the docs.
I could see op_clear() doing a PerlMemShared_free(cPVOPo->op_pv)
if the op type is OP_CUSTOM and xop_class is OA_PVOP_OR_SVOP.

I still don't know the answer to that.

Having had a quick look at op_clear(), I also note that there is a latent
bug in op_pv field handling​: the OP_DUMP etc cases fall through to the
OP_TRANS cases, which check for OPpTRANS_FROM_UTF etc private flags. If
those flags should at some point in the future overlap with private flags
in OP_DUMP etc, then things will go wrong.

I've fixed that now with v5.25.9-32-gabd07ec

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

From zefram@fysh.org

Dave Mitchell wrote​:

I suppose the question is whether to fix the code or the docs.

The nature of op handling is such that the code is canonical,
in all its twistiness. I've fixed the documentation in commit
258dae8. If we were to make op handling
significantly cleaner, that would be a big change, and should be a
comprehensive effort across all op types, not just a tweak in one place.

-zefram

@xsawyerx - Status changed from 'open' to 'pending release'

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release yesterday of Perl 5.28.0, this and 185 other issues have been
resolved.

Perl 5.28.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.28.0

If you find that the problem persists, feel free to reopen this ticket.

@khwilliamson - Status changed from 'pending release' to 'resolved'