Check Perl 5.18.4 Changes Before You Upgrade

You will finish with a small, repeatable upgrade checklist for the Perl 5.18.4 changes that can affect an application or build. The key result is a clear boundary between the historical release notes and the Perl version actually installed on your Linux host.

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. It compares 5.18.4 with 5.18.2 and deliberately skips 5.18.3, which was a short-lived broken release. If your starting point is 5.18.1, the document directs you to perl5182delta first. Do not treat 5.18.4 alone as a complete migration plan from an older Perl.

The changes fall into three useful groups:

• 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: the release addresses 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. They do not mean every Perl program 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 command only loads the module and prints its version:

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

A different version is normal on a newer Perl. In particular, seeing 6.04 does not prove or disprove that the old 5.18.4 bug fix is present. It tells you that this interpreter has a later module and that a module load works.

Now find where the module came from, if your packaging policy requires that distinction:

$ 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. Start without elevated privileges and without changing service configuration.

For code using Digest::SHA, run its normal hashing and verification tests, including the largest supported input your application 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, include a test case with a format declaration whose first meaningful character is a brace. Compare the rendered output with the known-good result from your application. Do not use a production report as an unreviewed test fixture if it contains sensitive data.

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

If you use the Perl debugger, test tab completion and a session that invokes a pager, then confirm that later filehandle inspection still reports the expected handle. Keep this interactive test separate from automated service tests because the manual describes debugger state, not 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 starting at 5.18.0, only when pseudo-fork was enabled, and only on Server 2003 R2 or newer systems. The leak was not reported on Windows XP SP3. A Linux host cannot reproduce that exact combination.

For a Windows upgrade, record the build configuration and test repeated calls to system and backticks in a long-running process. Do not infer pseudo-fork support from the operating system name alone. For a Linux-only deployment, keep the note in the review record but focus effort on the module, debugger and core code paths your application actually uses.

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 services. The upgrade itself is distribution-specific and is 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 until the new one has passed the application's acceptance checks.

If you find 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 the report before sending it. 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.