urlichs@smurf.ira.uka.de (Matthias Urlichs, Grosser Schlumpf) (06/02/89)
There is a possible (on my machine, very probable) race condition bug in GNU make, version 3.27. Scene: start_job in commands.c forks. The forked job starts up, does whatever it is supposed to do, and exits. The parent's signal handler gets started. Note that up to this point, the assignment "pid = vfork()" is not yet completed, so that the signal handler does not find the child's entry. Result: deadlock. My temporary workaround (putting a sleep(1) before the execv() call) confirmed this. My final workaround was to use sigblock(). However, not every system may have this. I have another problem: sometimes make starts a complex shell command, and then the shell just sits there and sleeps. I have no idea where this might come from but I suspect that the signal handling of make sometimes confuses its parents. A few minor points: - You should not signal(SIGCHLD,SIG_IGN). Use SIG_DFL instead. SIG_IGN will cause problems with some machines. - _Please_ don't use #ifdef USG for every feature not found in vanilla Sys5. Feature-dependent flags (-DVFORK -DBSDSIGNALS) would have saved me from a few hours' work. But aside from that, make seems to be an excellent program.
mcgrath%paris.Berkeley.EDU@GINGER.BERKELEY.EDU (Roland McGrath) (06/02/89)
You have a very old version of GNU Make. The last version released was 3.48.