---
name: dump
signature: 'dump LABEL'
signatures:
  - 'dump LABEL'
  - 'dump EXPR'
  - 'dump'
since: 5.0
status: documented
categories: ["Control flow"]
---

```{index} single: dump; Perl built-in
```

*[Control flow](../perlfunc-by-category)*

# dump

Cause the running program to produce a core dump immediately.

`dump` is a pre-historic Perl operator whose original purpose was to
freeze a running interpreter to a core file so that the (separately
supplied) `undump` utility could turn that core file back into an
executable. The resulting binary, when run, would restart the program
by jumping to `LABEL` via [`goto`](goto), skipping the startup cost of
re-reading and re-compiling the source. That workflow has been dead for
decades: `undump` was never shipped with Perl, modern operating systems
make core-to-executable conversion essentially impossible, and the
whole operator is now a historical curiosity. As of Perl 5.30 it must
be spelled `CORE::dump()` to discourage accidental use.

There is almost no situation in modern Perl where `dump` is the right
answer. If you reached for it because you want a stack trace, use
`Carp::confess`. If you want to exit abnormally,
use [`die`](die) or [`exit`](exit). If you want a snapshot of the
program state, use a checkpointing tool at the OS level.

## Synopsis

```perl
CORE::dump();
CORE::dump LABEL;
CORE::dump EXPR;
```

## What you get back

Nothing. `dump` does not return: control leaves the Perl interpreter
the way `abort(3)` leaves a C program. The process is terminated by
the kernel's core-dump handling (`SIGABRT`-style), with the usual
side effects: an exit status reflecting the signal, a possible
`core` file in the current directory if the user's `RLIMIT_CORE` and
the kernel's `core_pattern` allow it, and no orderly shutdown of the
Perl runtime. `END` blocks do **not** run. `DESTROY` methods do
**not** run. Buffered output on any filehandle is lost.

## Global state it touches

None directly. `dump` bypasses the normal end-of-program machinery
entirely — it does not read or write special variables, does not
flush buffers, and does not run destructors. Whatever state the
interpreter happens to be in at the moment of the call is what lands
in the core file.

## Examples

Trigger a core dump from a running program (requires `CORE::` as of
5.30):

```perl
CORE::dump();
```

With a label — originally, the `undump`-produced binary would resume
execution here. With `undump` gone this is purely decorative; the
process still just aborts:

```perl
RESTART:
    # ... initialisation ...
CORE::dump RESTART;
```

Runtime-computed label name (the `dump EXPR` form, available since
Perl 5.18):

```perl
my $label = pick_entry_point();
CORE::dump $label;
```

What you almost certainly want instead. For a post-mortem with a
stack trace:

```perl
use Carp;
Carp::confess("unreachable state: $state");
```

For a clean abnormal exit with a status code:

```perl
die "fatal: $reason\n";      # exit via $@, runs END / DESTROY
exit 1;                      # plain exit, runs END / DESTROY
```

## Edge cases

- **Spelling since 5.30**: a bare `dump` or `dump LABEL` at statement
  level is a compile-time error unless written as `CORE::dump` or
  `CORE::dump(...)`. This is deliberate — the core team made the
  operator hard to reach by accident.
- **`LABEL` is not resolved at call time**: historically the label
  was looked up only after `undump` reincarnated the program, so a
  typo would not be caught at `dump`-time. Today the point is moot —
  the program never resumes, so the label is pure documentation.
- **`dump EXPR`**: the expression is evaluated in scalar context and
  must yield a label name. It has no effect on the outcome, for the
  same reason.
- **Parser quirks**: `dump` has the same precedence as assignment
  and is exempt from the looks-like-a-function rule. `dump ("foo")
  . "bar"` parses with `"bar"` as part of the argument, not as a
  post-concatenation. In practice this only matters if you are
  writing `dump` at all, which you should not be.
- **Open files are lost**: any filehandle open at the moment of
  `dump` is gone when (in the historical workflow) the reincarnated
  program starts. The POD warning about "possible resulting
  confusion by Perl" dates from the era when someone might actually
  try this; today the warning is academic because nothing resumes.
- **Core files may not be produced**: whether a core file actually
  lands on disk depends on `ulimit -c`, the kernel's
  `kernel.core_pattern`, filesystem permissions, and whether the
  process is running under a supervisor that captures or discards
  core files. `dump` succeeding in aborting the process is not the
  same as a core file being available afterwards.
- **Portability**: on systems without meaningful core-dump support
  the operator reduces to "abort the process"; see
  `perlport` for historical notes.

## Differences from upstream

Fully compatible with upstream Perl 5.42.

## See also

- [`exit`](exit) — terminate the program normally, running `END`
  blocks and destructors; this is what you almost certainly want
  instead of `dump`
- [`die`](die) — raise an exception; with no handler it terminates
  the program but still runs `END` blocks and flushes output
- [`goto`](goto) — the control-transfer operator whose `LABEL` form
  `dump` was historically meant to cooperate with after reincarnation
- `Carp::confess` — stack-trace-on-exit, the
  modern answer for "I want to see program state at the point of
  failure"
- [`warn`](warn) — emit a diagnostic without terminating; combine
  with a stack-trace module when you want information without
  aborting
- `perlrun` — documents the historical `-u`
  command-line switch that performs a `dump` immediately after
  compilation