[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: diffutils 2.8.4 bug when make -j is used
From: |
Paul D. Smith |
Subject: |
Re: diffutils 2.8.4 bug when make -j is used |
Date: |
Mon, 14 Oct 2002 00:59:16 -0400 |
%% Paul Eggert <address@hidden> writes:
pe> It does smell like a 'make' bug to me, though I suppose it could
pe> be a kernel or shell bug too. Can you please try the following
pe> things?
pe> My suspicion is that your "make" is mishandling these dependencies:
pe> cmp.o diff3.o diff.o sdiff.o: paths.h
pe> by spinning off multiple subproceses to build cmp.o, diff3.o, etc;
pe> and that these subprocesses are each attempting to build paths.h
pe> separately.
Make will not spin off any subprocesses to handle the .o's that "try to
build paths.h"... unless your rule to build a .o includes an invocation
of a recursive make which seems unlikely... ?
And, at any rate, the algorithm for GNU make will never allow the
commands to build a target to be spawned before all of its prerequisites
are completed... barring a signal handling problem of the type which is
fixed in 3.80 (and assuming no bugs in the kernel/libc in the area of
SA_RESTART, signal handling, multiple reads from a single pipe, etc.)
pe> If my guess is right, we might have the following sequence of
pe> actions, where "1:" denotes subprocess #1 and "2:" denotes
pe> subprocess #2:
pe> 1: check whether paths.h exists and is up to date; it's not
pe> 1: start subshell to create paths.h
pe> 1: subshell creates paths.h as an empty, but up-to-date, file
pe> 2: check that paths.h exists and is up to date
pe> 2: compile diff3.o
pe> 2: compilation fails because paths.h is still empty
pe> 1: subshell writes data to paths.h
I don't understand why subprocess 1 and 2 would be "checking that
paths.h exists and is up to date" unless they are both instances of
make... and if you have multiple instances of make running in the same
directory at the same time, you _definitely_ will have race conditions!
It is not the function of make's job server to keep multiple instances
of make from bumping into each other: it just limits the total number of
concurrent jobs the build will invoke at the same time.
Is there something unusual about how the makefile(s) in this package are
constructed?
pe> If my guess is right, "make --debug=jobs" should report
pe> information confirming the suspicion, assuming you can reproduce
pe> the bug when the debugging flag is set.
I agree, though, that the output of this could be interesting.
--
-------------------------------------------------------------------------------
Paul D. Smith <address@hidden> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
- Re: diffutils 2.8.4 bug when make -j is used, Paul Eggert, 2002/10/13
- Re: diffutils 2.8.4 bug when make -j is used, Chris Bainbridge, 2002/10/13
- Re: diffutils 2.8.4 bug when make -j is used, Paul D. Smith, 2002/10/14
- Re: diffutils 2.8.4 bug when make -j is used, Paul Eggert, 2002/10/14
- Re: diffutils 2.8.4 bug when make -j is used,
Paul D. Smith <=
- Re: diffutils 2.8.4 bug when make -j is used, Chris Bainbridge, 2002/10/14
- Re: diffutils 2.8.4 bug when make -j is used, Paul D. Smith, 2002/10/14
- Re: diffutils 2.8.4 bug when make -j is used, Paul D. Smith, 2002/10/14
- Re: diffutils 2.8.4 bug when make -j is used, Martin Schlemmer, 2002/10/14
- Re: diffutils 2.8.4 bug when make -j is used, Paul Eggert, 2002/10/15