Re: parallel build failure with .c.o rule interrupted mid-step!

Mouse <[email protected]> Thu, 6 Mar 2025 18:46:08 -0500 (EST)
Newsgroups gmane.os.netbsd.current,gmane.os.netbsd.devel.toolchain
Message-ID <[email protected]>
> There's a race between the shell writing the final command-line to
> the pipe and the SIGPIPE being delivered, [...]

Is there?

My understanding is that the SIGPIPE is generated within the write()
call, and it is noticed and delivered in the syscall exit codepath.  If
so, the signal-generating write should never return as far as userland
is concerned.

The ktrace log quoted upthread shows the syscall returning

>>   3406   3406 make-2025.02.24. CALL  write(1,0x70addd3fda00,0x1f)
>>   3406   3406 make-2025.02.24. RET   write -1 errno 32 Broken pipe
>>   3406   3406 make-2025.02.24. PSIG  SIGPIPE SIG_DFL: code=SI_NOINFO

but this is meaningless; ktrace /bin/sh -c 'kill -KILL $$' also shows
kill(2) returning - presumably the ktrace record is written before the
syscall exit path tears down the process due to the signal.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B