Read perl5184delta Before You Touch Perl 5.18.4

perl5184delta is the release note for Perl 5.18.4, and it is worth five minutes before you blame your own code for a crash someone already fixed. This guide turns that document into a short, repeatable upgrade check rather than a wall of changelog text. The main job is keeping the historical release notes and the Perl actually installed on your Linux host clearly separate.

Allow about fifteen minutes for the read-only checks, plus whatever time your application's regression suite needs. You need a shell, the perl-doc package for the local manual, and access to the application's normal test commands. Nothing in this guide installs, removes, recompiles or replaces Perl.

1. Confirm which documentation and interpreter you are using

Start by checking the local manual and the interpreter separately. These are ordinary read-only commands and do not need sudo:

$ man -w perl5184delta
/usr/share/man/man1/perl5184delta.1.gz
$ perl -e 'print "$^V\n"'
v5.38.2
$ dpkg-query -W -f='${Package} ${Version}\n' perl-doc
perl-doc 5.38.2-3.2ubuntu0.6

Your version output will differ. On this host, the manual is supplied by the current perl-doc package and the interpreter is Perl 5.38.2. The manual itself describes the difference between Perl 5.18.4 and 5.18.2. It is a release note, not an upgrade command and not a claim that the installed interpreter is 5.18.4.

2. Read the exact 5.18.4 scope

Open the local document:

$ man perl5184delta

Its scope is narrow: 5.18.4 against 5.18.2, deliberately skipping 5.18.3, a short-lived broken release. Coming from 5.18.1 instead? The document sends you to perl5182delta first. Either way, do not treat 5.18.4 alone as a complete migration plan from an older Perl.

Three groups of change are worth separating in your head:

• Included modules and tools: Digest::SHA moved from 5.84_01 to 5.84_02, and perl5db.pl, the debugger implementation, moved from 1.39_10 to 1.39_11.
• Platform-specific behaviour: a memory leak affecting some Win32 builds using pseudo-fork, system or backticks was fixed. This does not describe ordinary Linux Perl builds.
• Core fixes: a Digest::SHA segfault, a 32-bit Visual C 2003 build problem with USE_64_BIT_INT, format parsing with a leading brace, a Valgrind complaint during interpreter cloning, and crashes involving undef *_; goto &sub or local *_; goto &sub.

The debugger fixes are also described as a tab-completion crash fix and as correct filehandle reset after a pager runs. Those details tell you which tests are worth running, not that every Perl program suddenly needs a debugger test or a Win32 test.

3. Check whether the affected module is present

Inspect the Digest::SHA version loaded by the interpreter you intend to upgrade. This only loads the module and prints its version, nothing more:

$ perl -MDigest::SHA -e 'print "Digest::SHA $Digest::SHA::VERSION\n"'
Digest::SHA 6.04

A different version is normal on a newer Perl. Seeing 6.04 here does not prove or disprove that the old 5.18.4 bug fix is present; it just confirms this interpreter has a later module and a module load works.

If your packaging policy needs to know where the module came from, ask:

$ perldoc -l Digest::SHA
/usr/share/perl/5.38/Digest/SHA.pm

The path is installation-specific. Record it with the Perl version and package manifest used by your distribution. Do not copy a module into a system Perl directory to force a version match; that creates an ownership and rollback problem. Use your normal package or application dependency mechanism instead.

4. Match the fixes to real regression tests

Run the smallest existing tests that exercise the affected areas, starting without elevated privileges and without touching service configuration.

For code using Digest::SHA, run its normal hashing and verification tests, including the largest input your application actually uses. A successful module load is only a smoke test: the release note records a segfault fix, so a clean process exit matters as much as the digest value.

For code using Perl formats, add a test case whose format declaration starts with a brace. Compare the rendered output against the known-good result from your application. Do not press a production report into service as an unreviewed test fixture if it holds sensitive data.

For code touching typeglobs and tail calls, isolate the relevant lines in a disposable test process. The affected forms are undef *_; goto &sub and local *_; goto &sub. Run under the exact interpreter being evaluated and check its exit status: a crash there is a release blocker for that workload, not a reason to repeat the test in a live service process.

Using the Perl debugger? Test tab completion and a session that runs a pager, then confirm that filehandle inspection afterwards still reports the expected handle. Keep this interactive check separate from your automated service tests, since the manual describes debugger state rather than application runtime behaviour.

5. Treat the Win32 fix as conditional

The platform note is not a general memory-leak guarantee. It concerns most Win32 Perls from 5.18.0 onward, only when pseudo-fork was enabled, and only on Server 2003 R2 or newer. Windows XP SP3 never showed the leak. A Linux host cannot reproduce that combination at all.

Planning a Windows upgrade? Record the build configuration and test repeated calls to system and backticks in a long-running process, and do not infer pseudo-fork support from the operating system name alone. On a Linux-only deployment, note the fix in your review record but put your effort into the module, debugger and core code paths your application actually touches.

6. Record the upgrade decision and recovery point

Before changing a production interpreter, save the package versions, interpreter output, dependency lock data and regression results. Schedule a maintenance window if the interpreter is shared by other services. The upgrade itself is distribution-specific and sits outside this manual's scope.

Do not remove the old interpreter or overwrite a working container or virtual environment as part of this check. If a later upgrade changes application behaviour, recovery means restoring the previously tested package set or image and rerunning the smoke tests. Keep the old environment around until the new one clears the application's acceptance checks.

Found a new core defect? Reduce it to a small test case and capture perl -V output. The manual points to perlbug for reporting:

$ perl -V > perl-version.txt
$ perlbug

perlbug is interactive and may prepare a report for the Perl porting team. Review it before sending. Do not include credentials, customer data or proprietary source. For a security issue in the Perl core, use the security reporting route documented by the installed manual rather than a public bug report.