497197 - Intermittent try server failures on Windows -- "No rule to make target"

Status: RESOLVED WORKSFORME

(Release Engineering :: General, defect)

Description

[Zack Weinberg (:zwol)]

Three try server runs this morning have failed the build on Windows with errors of the form

make[7]: *** No rule to make target `FOO', needed by `BAR'.  Stop.

Logs:

http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1244567488.1244571281.22483.gz
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1244559989.1244565044.11648.gz
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1244543905.1244549437.9561.gz

It does not appear to be limited to one slave, and it appears to have started happening today.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

The third one is a genuine error in the patch being tested, and failed on (at least) Linux too.

The second one appears to be from trying to use patch to apply a git diff with renames, the files don't get moved on linux and win32. Bug 446168 would help. That doesn't explain why win32 failed to compile and the other platforms did though.

Comment 2

[Zack Weinberg (:zwol)]

Ok, but that leaves the first one unexplained; that one was mine, and I can attest that it  consisted entirely of changes to existing files, and did not touch anything in /browser ...

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Indeed. I'm trying to figure out why objdir/browser/components/places/public/Makefile should be failing make export. At first glance it looks sanely formed.

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: diff of make -d output

I compared the Makefile from Zach's broken build on slave win11 to the next build try build, which completed on win1. They're essentially the same and the only differences relates to the topsrcdir, srcdir, and VPATH definitions, which use absolute paths and we have a different base path for the buildbot slave.

This attachment is generated by executing 'make -d export' in objdir/browser/components/places/public, then diffing the output for the working build on win1 vs the failing build on win11. It's a snippet, keeping the important differences and ignoring path differences (as above). 

For some reason make on win11 thinks that Makefile.in doesn't exist in the srcdir, but ls on /e/builds/slave/sendchange-win32-hg/build/browser/components/places/public/Makefile.in returns no error.

chkdsk finds no problem with the disk. win11 is one of the new slaves with an NTFS disk, which currently have a question mark of them.

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

Any idea what's happening here Ted ? The actual error is 

make[6]: Entering directory `/e/builds/slave/sendchange-win32-hg/build/objdir/browser/components/places'
D:/mozilla-build/msys/bin/perl.exe /e/builds/slave/sendchange-win32-hg/build/build/autoconf/make-makefile -t /e/builds/slave/sendchange-win32-hg/build -d ../../..  public/Makefile
D:/mozilla-build/msys/bin/perl.exe /e/builds/slave/sendchange-win32-hg/build/build/autoconf/make-makefile -t /e/builds/slave/sendchange-win32-hg/build -d ../../..  src/Makefile
creating browser/components/places/public/Makefile
D:/mozilla-build/msys/bin/perl.exe /e/builds/slave/sendchange-win32-hg/build/build/autoconf/make-makefile -t /e/builds/slave/sendchange-win32-hg/build -d ../../..  tests/Makefile
creating browser/components/places/src/Makefile
creating browser/components/places/tests/Makefile
make[7]: Entering directory `/e/builds/slave/sendchange-win32-hg/build/objdir/browser/components/places/public'
make[7]: Leaving directory `/e/builds/slave/sendchange-win32-hg/build/objdir/browser/components/places/public'
make[6]: Leaving directory `/e/builds/slave/sendchange-win32-hg/build/objdir/browser/components/places'
make[5]: Leaving directory `/e/builds/slave/sendchange-win32-hg/build/objdir/browser/components'
make[7]: *** No rule to make target `Makefile.in', needed by `Makefile'.  Stop.

Also http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1244583177.1244587436.12698.gz on win12 for a patch in parser/

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

The build nthomas links to in comment 5 is the last example of this fail - all win32 try builds today have not come up on this so far.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

Just checked in on the past 24 hours of try builds and this still hasn't re-appeared.

Comment 8

[Zack Weinberg (:zwol)]

That exact failure mode does seem to be gone, but I am still getting rando-failures, e.g. last night one of my builds got a "Virtual memory exhausted" in the link phase.

Comment 9

[Chris Cooper [:coop] (he/him)]

(In reply to comment #8)
> That exact failure mode does seem to be gone, but I am still getting
> rando-failures, e.g. last night one of my builds got a "Virtual memory
> exhausted" in the link phase.

Not trying to sweep this under the rug, but let's get a separate bug on file for the "Virtual memory exhausted" error (no reason to suspect it's related) and reopen this one if it recurs.