Re-enable LeakSanitizer runs on Ubuntu 26.04

[sevan]

ubuntu-latest target currently means Ubuntu 24.04, whilst the latest actual release of Ubuntu is 26.04.
Target 26.04 to see if LeakSanitzer still struggles when GDBM support is included.
Part of PR #24765

• This set of changes does not require a perldelta entry.

[sevan]

op/kvhslice.t ........................................................ ok
==23616==LeakSanitizer has encountered a fatal error.
==23616==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==23616==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
op/fork.t ............................................................ ok

[sevan]

aha, the PERL_UNICODE job built with sanitizers sheds a little light. Note the warning on the first line:

==29183==WARNING: TestPTrace() failed to fork (errno 11)
==29183==LeakSanitizer has encountered a fatal error.
==29183==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==29183==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
op/fork.t ............................................................ ok

[jkeenan]

ubuntu-latest target currently means Ubuntu 24.04, whilst the latest actual release of Ubuntu is 26.04. Target 26.04 to see if LeakSanitzer still struggles when GDBM support is included. Part of PR #24765

1. Do we need two separate pull requests (this and GH Re-enable LeakSanitizer runs #24765)?

2. Who decides what ubuntu-latest points to? Canonical? GitHub? Us? (I ask because I'm a long-time Ubuntu user and have become accustomed to the pacing of their releases. Though the latest actual release may be 26.04, I haven't actually received prompts to upgrade from 24.04. I expect that will happen in a month or two.)

[sevan]

We need one pull request, but it's just easier from the CI run side to raise 2 pull requests and also it remains here as evidence, given that it is security sensitive.
Regarding who decides, it's Microsoft. See the readme in the github.com/actions/runner-images repo.

[sevan]

Ok, I dropped the install if libgdbm & libdb, and the error remains. So the issue is not related to libgdbm nor libdb.
It's always when it comes to run op/fork.t it seems, from the logs.

[sevan]

PR #24765 is the change I want to land. I'm just using this PR to test against Ubuntu 26.04 and will close it regardless of what happens to #24765.

[tonycoz]

PR #24765 is the change I want to land. I'm just using this PR to test against Ubuntu 26.04 and will close it regardless of what happens to #24765.

You can enable CI in your own fork, there's no need to make a PR:

and then set DO_EXTENDED_TESTING:

This will show the status of CI with a little cross or tick when you switch to that branch:

[sevan]

You can enable CI in your own fork, there's no need to make a PR:

Thanks for the pointer. I had disabled it all because when you're syncing the fork with upstream, it triggers a CI run, and then you get a load of unwanted emails.