New smoke failures on lib/charnames.t

[richardleach]

Description
https://perl5.test-smoke.org/submatrix?test=../lib/charnames.t

Test failures:
On FreeBSD, CentOS, Debian, Android smokers:
~~ ../lib/charnames.t .......................................... FAILED Non-zero exit status: 9

From Android:

v5.31.10-14-gafd41ae4e7
---------------------- ----------------------------------------------------
O  F  O  O              -Alibpth="/system/lib /vendor/lib" (*1)
O  O  O  O              -Alibpth="/system/lib /vendor/lib" -Duse64bitint (*1)
|  |  |  |
|  |  |  +------------  perlio DEBUGGING
|  |  +---------------  stdio DEBUGGING
|  +------------------  perlio
+---------------------  stdio

On Win10:
~~ ../lib/charnames.t .......................................... FAILED Non-zero exit status: 255 No plan found in TAP output

Steps to Reproduce
Build blead.

Expected behavior
No test failures in lib/charnames.t

Perl configuration
TODO

Manual build running now, will update this issue when done...

[jkeenan]

As we've been discussing on and off on #p5p, these failures have been appearing intermittently for several months. I got one when I was testing the perl-5.31.10 tarball. But I couldn't reproduce it.

[richardleach]

D'oh, sorry. I must surely have seen some of that chat on #p5p.

[xsawyerx]

@khwilliamson What do you think?

[khwilliamson]

Here's the commit message that references this ticket

We are seeing an occasional smoke failure in the experimental regular
expression Unicode property wildcard feature for the name property.
This is not reproducible, and neither valgrind nor asan shows anything.
All the failures I have seen involve looking up NULL. Now it could be
something special about that name, or merely that it is the first in the
test to be checked. This commit seeks to find out by skipping that
test. If we stop getting these intermittent failures, it points one
direction; if they continue with 0x01, instead, it points in another.

Since that commit we have not seen any failures. What I think should now happen is that we ship it as-is, and I'll add debugging code early in 5.33 so that when this intermittent, rare problem crops up, it can record information. This only fails on a single name, NULL (and its synonyms), and it is an experimental feature, I think that is an acceptable way forward.

[jkeenan]

On 4/16/20 11:38 AM, Karl Williamson wrote: Here's the commit message that references this ticket We are seeing an occasional smoke failure in the experimental regular expression Unicode property wildcard feature for the name property. This is not reproducible, and neither valgrind nor asan shows anything. All the failures I have seen involve looking up NULL. Now it could be something special about that name, or merely that it is the first in the test to be checked. This commit seeks to find out by skipping that test. If we stop getting these intermittent failures, it points one direction; if they continue with 0x01, instead, it points in another. Since that commit we have not seen any failures. What I think should now happen is that we ship it as-is, and I'll add debugging code early in 5.33 so that when this intermittent, rare problem crops up, it can record information. This only fails on a single name, NULL (and its synonyms), and it is an experimental feature, I think that is an acceptable way forward.

+1