[pups] 2.11BSD "make unix" aborts Error 141

[sms@2BSD.COM (Steven M. Schultz)]

Hi -

> From: norman at nose.cs.utoronto.ca (Norman Wilson)
> 0141 (octal) is 'a.  141 decimal is 0215 octal, i.e. carriage return with
> parity.

	And I remembered that (correctly as it turns out) without looking
	at ascii(7) <g>

> What seems more likely is that 141 decimal is 0200 + 13 decimal.  If a
> simple value returned by wait, that means SIGPIPE + core image, which
> seems unlikely.  If an exit status as displayed by the shell, it just

	It's, if I recall, being displayed by 'make'.   There's no coredump
	so the interpretation of 0141 is that of an exit status.  It's been
	a while since I've looked into the problem - it was quite annoying
	to run the sequence (that was causing make to cease) manually and not
	have it happen the same way.
	a 'shell'

> means SIGPIPE (128 + signal number).  Or is signal 13 different in 2.11
> than in V7?  (That seems even less likely.)

	Ah, ok - that makes sense too.  No, SIGPIPE is the same as it's always
	been since it was first defined as 13

> SIGPIPE doesn't seem entirely unreasonable as an accident that could
> happen if something goes wrong in the assembly-language-code-tweaking
> part of the kernel build.

	But something is causing the assembler to exit prematurely and break
	the pipe in the first place.

	SIGPIPE happens, of course, when a writer process writes to a pipe
	where the receiving/reading process has exited.   'as' is exiting
	prematurely - that can be determined by looking at the partially
	created (or empty) .s file that gets left behind.

> Of course if it's a random value handed to sys exit, all rules are off.

	What might be needed is a decent (or existent ;)) syscall tracing
	capability.  That combined with the capability to "coredump a non-0
	exit process) might be enough to track down what's causing 'as'
	to depart the scene prematurely.

	Cheers,
	Steven Schultz