Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site allegra.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!jpl
From: jpl@allegra.UUCP (John P. Linderman)
Newsgroups: net.bugs.uucp,net.bugs.4bsd
Subject: Re: hung line help needed
Message-ID: <2918@allegra.UUCP>
Date: Fri, 23-Nov-84 16:08:10 EST
Article-I.D.: allegra.2918
Posted: Fri Nov 23 16:08:10 1984
Date-Received: Sat, 24-Nov-84 02:50:06 EST
References: <449@godot.UUCP> <85@daemon.UUCP> <492@godot.UUCP> <498@astrovax.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 22

>In review: the subject is the hung uucico processes that we have here
>at astrovax and godot.  This is when running rtiuucp under 4.2 BSD.
>A typical hang point is main()/conn()/Acuopn()/vadopn()/expect()/read().
>allegra has also reported such problems with honey danber under 4.2 BSD.

To be more explicit, Phil Karn and I would occasionally find a hung
honey danber uucico.  The processes were not always in the same place.
We found, after tweaking pstat to provide a little extra information,
that the common theme was that the processes had an alarm pending, but
with alarms masked off.  Alarms are not masked off by honey dan-ber,
so the problem appears to be a race somewhere in the 4.2 signal code,
somehow failing to reset signals following a longjmp out of an alarm
handler.  We replaced alarm calls with a macro-sequence that explicitly
set SIGALRM on in the signal mask before doing the alarm call.  We haven't
seen a hung uucico since.

In summary, honey danber seems to be guilty only of exercising alarms
rather more heavily than typical programs, thereby exposing some problems
in the underlying 4.2 operating system.  We didn't have problems with
honey danber under 4.2, we exposed problems with 4.2 through honey danber.

John P. Linderman  Department of Alarming Errors  allegra!jpl