bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #58979] Recursive make using jobserver hangs at completion


From: Paul D. Smith
Subject: [bug #58979] Recursive make using jobserver hangs at completion
Date: Thu, 20 Aug 2020 10:22:21 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36

Follow-up Comment #6, bug #58979 (project make):

I definitely am not saying there's not a bug in GNU make.  However, note that
traditional race conditions aren't common for GNU make because (a) it's
single-threaded and (b) the interaction between processes is mediated by
writing/reading a single byte to a pipe, which is managed by the kernel (which
presumably does not have race conditions!)

The only possible area where races can occur (barring a bug in the kernel) is
during signal handling.  This could be happening, as this is not a trivial
area, but just to note that I personally use GNU make 4.3 with varying levels
of -j on Linux systems of all different versions and hardware of all types, on
large builds MANY times a day, and I've not seen these issues.  So a bug in
GNU make may exist but it must be extremely difficult to hit.

Just to be up-front, I personally will likely not have time to reconstruct and
debug a complex makefile environment (particularly if the problem is very
intermittent/doesn't happen for me).  Perhaps Dmitry will have more time for
this.

If you do have a repro case it may be more feasible for us to suggest ways for
you to debug the environment that fails.  I've already suggested one way
forward, using -n.  I'd be interested to know if that had any results.

Other options likely involve modifying the GNU make code.  For example we
could point you to the places in the code where we read a byte from the
jobserver pipe and write a byte to the jobserver pipe.  If you print a debug
note every time that happens we may discover something interesting. 
Particularly if we see a matched set of read/write but there are still bytes
missing, then it's clear something else is reading the pipe that shouldn't be.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58979>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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