[pups] 2.11BSD "make unix" aborts Error 141
Steven M. Schultz
sms at 2BSD.COM
Thu Mar 20 03:59:03 AEST 2003
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
More information about the TUHS
mailing list