bug-make
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]