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

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:


  Message sent via Savannah

Reply via email to