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/