On 02/05/2012 05:52 AM, Nicholas Clark wrote:
On Sun, Feb 05, 2012 at 11:32:22PM +1100, Tony Cook wrote:
On Sun, Feb 05, 2012 at 10:53:00AM +0000, Nicholas Clark wrote:
On Sat, Feb 04, 2012 at 06:54:00PM -0500, George Greer wrote:
v5.15.7-245-g7620cb1 Configuration (common) -A -Dcc=clang append:ccflags="
-fcatch-undefined-behavior "
----------- ---------------------------------------------------------
O O O O
F O O O -Duseithreads
| +--------- -DDEBUGGING
+----------- no debugging
Failures: (common-args) -A -Dcc=clang append:ccflags=" -fcatch-undefined-behavior
"
[default] -Duseithreads
../t/porting/podcheck.t.....................................FAILED
Non-zero exit status: 2
Bad plan. You planned 1517 tests but ran 0.
Odd:
Can't open 'lib/feature.pm-new': No such file or directory
# Looks like you planned 1517 tests but ran 0.
porting/podcheck.t ................................................
Dubious, test returned 2 (wstat 512, 0x200)
but that test passed before, and passed again afterwards, so where did that
file come from, and where did it go to?
Maybe a race with regen/feature.pl as run by porting/regen.t
Yes, independently after some digging, I'd reached this conclusion.
I'd not mailed yet because I
a) surprised that we'd never seen it before
b) still wondering what else might have similar problems
c) wondering if there's a way to log all the filenames that get opened
without it being prohibitively expensive.
(possibly the right flags to strace)
Nicholas Clark
podcheck goes to some lengths to avoid transitory file issues. But
obviously not entirely. Here are the relevant comments from it:
# The file should already have been opened once to get here, so if
# fails, just die. It's possible that a transitory file containing a
# pod would get here, but not bothering to add code for that very
# unlikely event.
This is triggered only when there is some issue that forces the file to
be read again. The major case where that happens is when two pods have
the same name, but the file's containing them have differing SHA-1's.
It will warn that there are duplicate names (and hence it is ambiguous
which one is meant by a link to that name), but it doesn't want to warn
if they really are the same pod. This happens mostly as a result of the
pod being extracted by the build process from some other file. In this
infrequent case, podcheck re-reads the files, extracting just the pods,
then comparing just those portions of the files.
Without checking further, I believe that this is what happened here. The
temporary file has pod in it, and is not the same file as its generating
source, but has the same NAME; and was gone when podcheck tried to probe
more deeply.
That it has happened only once in the thousands of times podcheck has
been run indicates that it is indeed rare. I suppose what I could do is
if the open fails because the file is gone, assume it was a temporary,
and now there aren't two files with the same NAME.
