unix@cbosgd.UUCP (03/11/85)
From: Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP>
Unix Technical Discussions Sat, 09 Mar 1985 Volume 1 : Issue 5
Today's topics:
Idea on debugging the kernel
Warning on mis-use of wait(2) (2)
SysV IPC Doc'n (2)
Common sh script mis-use of "trap"
----------------------------------------------------------------------
Date: 31 Jan 85 07:59:31 GMT
From: haynes%ucsce.ucscc.UUCP%Berkeley@ucscc.UUCP
Subject: How do you debug the kernel?
This idea comes from the dear old Burroughs B5500
Have a global word (might as well be 64 bits, they're cheap) and call it
options. Make a system call or ioctl that can set and clear the bits of
options and can read the contents. Make a nice command for diddling and
displaying the bits. You could do this with adb, but we're talking about
a nice system, so you might as well go all the way. Give each bit of the
option word a name, and write some macros so you can refer to them by name.
Now you put printfs or experimental code into the kernel, and have each one
controlled by a bit in the option word. Use you command to turn the option
on when you want to see what's going on and turn it back off when you have
enough data. Might as well use some of the option bits to control printfs
that are already in the system. Would be a convenient way to turn off
file system full messages or table full messages when you already know
about the problem and are trying to do something about it.
ucbvax!ucscc!haynes
------------------------------
Date: 28 Feb 85 12:33:26 GMT
From: andy@istbt.UUCP (Andy Greener)
Subject: Shell out bug in pg (but a more general problem)
We recently had an intermittent problem when using the "shell out" in
pg (Sys V.2 on Vax 750). Depending on the length of the preceding
pipeline (the problem only occurs when pg is the tail of a pipeline)
pg would resume without waiting for the child shell to complete -
result: two processes trying to read from the terminal.
On investigating in the pg source I found that it does a "wait(0)"
without testing the return pid (this "mechanism" is common in Sys V
code as far as I can tell). It is relying on the wait being interrupted
by the death-of-a-child signal when the sub-process terminates.
However, the Sys V shell makes the last process in a pipeline the parent
of all the others, so if the pipeline contains a few processes the
first may already have died, resulting in the wait(0) returning immediately
and pg carrying on its merry way.
It seems that this practice of relying on a signal to terminate the
wait is inherently dangerous, especially as the signal(2) man section
states in reference to SIGCLD and SIGPWR:
"Their use in new programs is strongly discouraged"
Does one hand at AT&T know what the other is doing? It is almost beyond
comprehension that such a major screw up has seen the light of day.
It undoubtedly will produce unforseen effects elsewhere (eg Sys V tar
forks mkdir, and uses the same wait mechanism - we had problems here too).
Do they do any testing of their "products"? My impression of
Sys V.2 is that it was rushed out the door; there are other problems
which we have come across that are really only of interest to other
Sys V sites. I won't bore you with the details here, but I will respond
to mailed requests and if there's lots of interest I'll post to the net.
Andy Greener Imperial Software Technology
London, ENGLAND.
{mcvax, qtlon, inset, root44}!ist!andy
"UNIX System V: from now on consider it sub-standard"
------------------------------
Date: 7 Mar 85 23:47:05 GMT
From: guy@rlgvax.UUCP (Guy Harris)
Subject: Re: Shell out bug in pg (but a more general problem)
Code which starts up a child process and does a general "wait" for any
children without checking that the child they're interested in is what
exited is broken, due, as you mentioned, to the fact that the shell's
way of setting up pipelines creates unexpected edges in the family
tree of processes. This was discovered in the 4.2BSD "crypt" a while
ago, so such broken code is not restricted to System V.
Any such code out there should be redone, and all future code which
waits for children *must* check that the process which exited is the
process that was being waited for.
I don't know how seriously to take the comment about SIGCLD and SIGPWR,
considering 1) the System III manual said they'd go away, and they're still
here and 2) System V's "init" uses both of those signals.
--
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
------------------------------
Date: 27 Feb 85 21:42:53 GMT
From: dre@ptsfa.UUCP (Doug East)
Subject: SysV IPC
Does anyone know of some literature, books, manuals (except
the Programmers Manual), or otherwise concerning how to use
IPC (messages, semaphores, pipes) on System V?
The Programmer's Reference Manual is not too clear on how to
effectively use this facility so any help would be appreciated.
Thanks in advance,
Doug East
..!dual!ptsfa!dre
------------------------------
Date: 4 Mar 85 15:09:45 GMT
From: hbb@hou5a.UUCP (H.B.Braude)
Subject: Re: SysV IPC
With the 3B2/300 computer, the IPC option comes with a very good document
on how it is used. The document Select Code is 305-444 and the COMCODE is
403778467 (taken from the first page of the document.)
Ask your sales rep.
--
Harlan B. Braude
{most "backbone" sites}!hou5a!hbb
------------------------------
Date: 25 Feb 85 22:48:56 GMT
From: msb@lsuc.UUCP (Mark Brader)
Subject: Useful sh construct enhances Pnews and Rnmail
The shell scripts Pnews and Rnmail, which are part of rn,
both allow you to temporarily escape to your favorite editor,
then they take over control again.
If your editor is one that catches interrupts and does something
useful with them (such as ed or qed, I don't know about vi),
then you want to be able to issue interrupts while you're inside
Pnews. But as distributed, Pnews says:
trap "" 2
${VISUAL-${EDITOR-$defeditor}} $tmpart $oldart
In other words, all interrupts are ignored while the editor is running.
This was obviously done to protect Pnews itself from being interrupted.
But, as sh(1) explains, if interrupts are turned off this way, the
effect is propagated to anything called from sh (including another sh
where you might try turning them back on; doesn't work).
In fact there is another way to turn off interrupts, which is NOT
propagated to children. It's not mentioned in sh(1), and I think it
should be; it's sufficiently non-obvious that I think it's worth posting.
Ta-da....
trap : 2
In other words, call a no-op upon interrupt.
*EMPHASIS*
This is what should be used by sh scripts that call programs that
catch interrupts. (Also sh scripts that want to allow the user to
interrupt some command without the script losing control.)
*END EMPHASIS*
I have patched our local copies of Rnmail and Pnews so that they
work this way now (and they do the same thing with quits... no reason to
assume what the editor will do with them).
Since I can't depend on other sh scripts being written this way, I
have also patched our local copy of the qed editor so that it
does not ignore interrupts if stdin is a tty, even if they were
being ignored when it was invoked.
Mark Brader
P.S. utzoo!henry, who told me about this, thinks it's true for all Bourne
shell versions. We run V7 locally, and my references to sh(1) are for V7.
------------------------------
End of Unix Technical Discussions
*****************************
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)