Dump dump

[p5pRT]

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

Searchable as RT127405$

[p5pRT]

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.)

Perl Info

``` 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. ```

[p5pRT]

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

[p5pRT]

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

[p5pRT]

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

[p5pRT]

From @epa

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

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

-- Ed Avis \eda@&#8203;waniasset\.com

[p5pRT]

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?

[p5pRT]

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@&#8203;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

[p5pRT]

From @leonerd

On Mon\, 23 Sep 2019 12​:43​:53 +0200 demerphq \demerphq@&#8203;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/

[p5pRT]

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@&#8203;leonerd\.org\.uk wrote​:

On Mon\, 23 Sep 2019 12​:43​:53 +0200 demerphq \demerphq@&#8203;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/

[p5pRT]

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

[p5pRT]

From @Leont

On Mon\, Sep 23\, 2019 at 11​:48 AM Ed Avis via RT \perlbug\-followup@&#8203;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

[p5pRT]

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.

[p5pRT]

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.

[p5pRT]

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?

[p5pRT]

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.

[p5pRT]

From @Leont

On Wed\, Sep 25\, 2019 at 3​:28 PM Sergey Aleynikov via RT \perlbug\-followup@&#8203;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

[p5pRT]

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.

[p5pRT]

From @Leont

On Wed\, Sep 25\, 2019 at 7​:34 PM Sergey Aleynikov via RT \perlbug\-followup@&#8203;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