From @epa

Created by @epa

The dump() builtin has been deprecated and barely working for as long
as I can remember. Even back in 2002 it 'has probably outlived most
of its usefulness.' Is it finally time to get rid of it?

If that is too much, then at least the unqualified use of dump()
rather than CORE​::dump(), which has given a deprecation warning since
2002, should go. (Arguably the deprecation warning was for the
feature as a whole rather than just invoking it without the CORE​::
prefix, but either way...)

(Personally I would like dump() to return the stringification of a
data structure, like Data​::Dumper​::Dumper and as the CPAN module
Data​::Dump currently provides, but that is for another day.)

Flags:
    category=core
    severity=low

Site configuration information for perl 5.22.1:

Configured by Red Hat, Inc. at Mon Dec 14 11:14:02 UTC 2015.

Summary of my perl5 (revision 5 version 22 subversion 1) configuration:
   
  Platform:
    osname=linux, osvers=4.3.0-1.fc24.x86_64, archname=x86_64-linux-thread-multi
    uname='linux buildvm-04-nfs.phx2.fedoraproject.org 4.3.0-1.fc24.x86_64 #1 smp mon nov 2 16:27:20 utc 2015 x86_64 x86_64 x86_64 gnulinux '
    config_args='-des -Doptimize=none -Dccflags=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -Dldflags=-Wl,-z,relro  -Dccdlflags=-Wl,--enable-new-dtags -Wl,-z,relro  -Dlddlflags=-shared -Wl,-z,relro  -Dshrpdir=/usr/lib64 -DDEBUGGING=-g -Dversion=5.22.1 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='  -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='5.3.1 20151207 (Red Hat 5.3.1-2)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags ='-Wl,-z,relro  -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib64 /lib64 /usr/lib64 /usr/local/lib /usr/lib /lib/../lib64 /usr/lib/../lib64 /lib
    libs=-lpthread -lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.22.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.22'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,--enable-new-dtags -Wl,-z,relro '
    cccdlflags='-fPIC', lddlflags='-shared -Wl,-z,relro  -L/usr/local/lib -fstack-protector-strong'

Locally applied patches:
    Fedora Patch1: Removes date check, Fedora/RHEL specific
    Fedora Patch3: support for libdir64
    Fedora Patch4: use libresolv instead of libbind
    Fedora Patch5: USE_MM_LD_RUN_PATH
    Fedora Patch6: Skip hostname tests, due to builders not being network capable
    Fedora Patch7: Dont run one io test due to random builder failures
    Fedora Patch15: Define SONAME for libperl.so
    Fedora Patch16: Install libperl.so to -Dshrpdir value
    Fedora Patch22: Document Math::BigInt::CalcEmu requires Math::BigInt (CPAN RT#85015)
    Fedora Patch26: Make *DBM_File desctructors thread-safe (RT#61912)
    Fedora Patch27: Make PadlistNAMES() lvalue again (CPAN RT#101063)
    Fedora Patch28: Make magic vtable writable as a work-around for Coro (CPAN RT#101063)
    Fedora Patch200: Link XS modules to libperl.so with EU::CBuilder on Linux
    Fedora Patch201: Link XS modules to libperl.so with EU::MM on Linux


@INC for perl 5.22.1:
    /usr/local/lib64/perl5
    /usr/local/share/perl5
    /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib64/perl5
    /usr/share/perl5
    .


Environment for perl 5.22.1:
    HOME=/home/eda
    LANG=en_GB.UTF-8
    LANGUAGE (unset)
    LC_COLLATE=C
    LC_CTYPE=en_GB.UTF-8
    LC_MESSAGES=en_GB.UTF-8
    LC_MONETARY=en_GB.UTF-8
    LC_NUMERIC=en_GB.UTF-8
    LC_TIME=en_GB.UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/eda/bin:/home/eda/bin:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/sbin:/usr/sbin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

Please ignore autogenerated disclaimer after this point.

This email is intended only for the person to whom it is addressed and may contain confidential information. Any retransmission, copying, disclosure or other use of, this information by persons other than the intended recipient is prohibited. If you received this email in error, please contact the sender and delete the material. This email is for information only and is not intended as an offer or solicitation for the purchase or sale of any financial instrument. Wadhwani Asset Management LLP is a Limited Liability Partnership registered in England (OC303168) with registered office at 40 Berkeley Square, 3rd Floor, London, W1J 5AL. It is authorised and regulated by the Financial Conduct Authority.

From @Abigail

On Thu, Jan 28, 2016 at 04​:27​:51AM -0800, Ed Avis wrote​:

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

This is a bug report for perl from eda@​waniasset.com,
generated with the help of perlbug 1.40 running under perl 5.22.1.

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

The dump() builtin has been deprecated and barely working for as long
as I can remember. Even back in 2002 it 'has probably outlived most
of its usefulness.' Is it finally time to get rid of it?

If that is too much, then at least the unqualified use of dump()
rather than CORE​::dump(), which has given a deprecation warning since
2002, should go. (Arguably the deprecation warning was for the
feature as a whole rather than just invoking it without the CORE​::
prefix, but either way...)

I don't think it will be a great loss if dump() gets dumped.

Has it ever worked in a useful way? I started using perl in 1995,
and even then you were advised not to even think of using it.

(Personally I would like dump() to return the stringification of a
data structure, like Data​::Dumper​::Dumper and as the CPAN module
Data​::Dump currently provides, but that is for another day.)

That I think should remain on CPAN. But removing dump() allows
modules to export a "dump" subroutine.

Abigail

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

From zefram@fysh.org

Abigail wrote​:

Has it ever worked in a useful way?

Its usefulness always depended on the availability of the undump utility,
which turns the core dump into an executable. (If you think about it,
these are really quite similar kinds of file, both specifying mainly
a program's memory layout and content.) undump is necessarily quite
OS-specific, so the availability was only ever patchy at best. There is
a Linux ELF port, but it's not widely packaged.

The actual trick that dump+undump achieves has really gone out of
fashion since the 1980s. This can partly be attributed to faster
machines making the startup delays smaller, but countervailing that we
use bigger programs and have more stringent performance expectations.
Perhaps the unpopularity is due to the embuggerance the technique incurs
with the modern high usage of dynamic linking.

You'd think there'd still be a niche for it around Perl, with some people
being awfully concerned about Moose startup times. But it's a terrible
effort to go to for each affected program, so only really appealing when
you have a single specific large-footprint frequently-invoked program
(like Emacs, the prototypical undump user). The process is quite
contrary to the dynamism we're accustomed to with Perl. Compare also
how much effort we've put into bytecode caching, another effort to reduce
startup times.

-zefram

From @epa

Even for emacs, the undump / unexec approach might be going away​:

http​://lwn.net/SubscriberLink/673724/a5165e8736a4fac2/

--
Ed Avis <eda@​waniasset.com>

From @epa

In Perl 5.30, dump is no longer a reserved word. You have to say CORE​::dump().

Out of interest what was the rationale for keeping the code around as CORE​::dump() rather than removing it altogether? Does it have any users?

From @demerphq

I remember FC saying he used it for breakpointing when he is debugging.
That way he has a well defined C level sub he could breakpoint in the
debugger which he could then call from perl as needed.

Yves

On Mon, 23 Sep 2019, 11​:48 Ed Avis via RT, <perlbug-followup@​perl.org>
wrote​:

In Perl 5.30, dump is no longer a reserved word. You have to say
CORE​::dump().

Out of interest what was the rationale for keeping the code around as
CORE​::dump() rather than removing it altogether? Does it have any users?

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=127405

From @leonerd

On Mon, 23 Sep 2019 12​:43​:53 +0200
demerphq <demerphq@​gmail.com> wrote​:

I remember FC saying he used it for breakpointing when he is
debugging. That way he has a well defined C level sub he could
breakpoint in the debugger which he could then call from perl as
needed.

Isn't that what study() is used for too?

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk | https://metacpan.org/author/PEVANS
http​://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

From @demerphq

Oh. Shoot. Maybe I'm confusing the two. Probably. Good catch.

Yves

On Mon, 23 Sep 2019, 12​:47 Paul "LeoNerd" Evans, <leonerd@​leonerd.org.uk>
wrote​:

On Mon, 23 Sep 2019 12​:43​:53 +0200
demerphq <demerphq@​gmail.com> wrote​:

I remember FC saying he used it for breakpointing when he is
debugging. That way he has a well defined C level sub he could
breakpoint in the debugger which he could then call from perl as
needed.

Isn't that what study() is used for too?

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk | https://metacpan.org/author/PEVANS
http​://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

From @Abigail

On Mon, Sep 23, 2019 at 02​:48​:39AM -0700, Ed Avis via RT wrote​:

In Perl 5.30, dump is no longer a reserved word. You have to say CORE​::dump().

Out of interest what was the rationale for keeping the code around as CORE​::dump() rather than removing it altogether? Does it have any users?

How would we know whether it has any users? Or rather, can we ever know
it doesn't have any users?

Abigail

From @Leont

On Mon, Sep 23, 2019 at 11​:48 AM Ed Avis via RT
<perlbug-followup@​perl.org> wrote​:

In Perl 5.30, dump is no longer a reserved word. You have to say CORE​::dump().

Out of interest what was the rationale for keeping the code around as CORE​::dump() rather than removing it altogether? Does it have any users?

What would be the rationale of removing it?

Is it standing in anyone's way?

Leon

From @dur-randir

I occasionally use CODE​::dump to actually generate a core file programmatically instead of sending SIGABRT to $$, as the latter is async and may arrive sometime later, not exactly where I need it.

From @epa

Perhaps the documentation should be changed? It currently says

Primarily this is so that you can use the undump program (not supplied)
to turn your core dump into an executable binary...

It could instead say something like

Primarily for debugging purposes. The older function of making an executable
(via a separate 'undump' program) is now obsolete.

From @eserte

Dana Tue, 24 Sep 2019 03​:53​:37 -0700, randir reče​:

I occasionally use CODE​::dump to actually generate a core file
programmatically instead of sending SIGABRT to $$, as the latter is
async and may arrive sometime later, not exactly where I need it.

Would it be possible to use PERL_SIGNALS=unsafe to get the non-deferred behavior?

From @dur-randir

On Tue, 24 Sep 2019 13​:37​:01 -0700, slaven@​rezic.de wrote​:

Would it be possible to use PERL_SIGNALS=unsafe to get the non-
deferred behavior?

It's async kernel delivery, not async perl handling, what's the culprit here.

From @Leont

On Wed, Sep 25, 2019 at 3​:28 PM Sergey Aleynikov via RT
<perlbug-followup@​perl.org> wrote​:

On Tue, 24 Sep 2019 13​:37​:01 -0700, slaven@​rezic.de wrote​:

Would it be possible to use PERL_SIGNALS=unsafe to get the non-
deferred behavior?

It's async kernel delivery, not async perl handling, what's the culprit here.

That doesn't sound right. POSIX requires that "If the value of pid
causes sig to be generated for the sending process, and if sig is not
blocked for the calling thread and if no other thread has sig
unblocked or is waiting in a sigwait() function for sig, either sig or
at least one pending unblocked signal shall be delivered to the
sending thread before kill() returns."

Leon

From @dur-randir

On Wed, 25 Sep 2019 10​:23​:46 -0700, LeonT wrote​:

POSIX requires that ...

Never thought about this. Is it also true for windows builds (aka are they POSIX compliant)? But this still requires running under unsafe signals, which is not the default and not always possible to set.

From @Leont

On Wed, Sep 25, 2019 at 7​:34 PM Sergey Aleynikov via RT
<perlbug-followup@​perl.org> wrote​:

Never thought about this. Is it also true for windows builds (aka are they POSIX compliant)?

No, Windows is very much not a POSIX, and in fact almost nothing about
signals on Windows is usable.

But this still requires running under unsafe signals, which is not the default and not always possible to set.

No it doesn't. Deferred signaling only affects Perl's signal handlers,
it doesn't affect a lack of an explicit signal handler.

Leon