Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sdcc3.UUCP
Path: utzoo!linus!decvax!ittvax!dcdwest!sdcsvax!sdcc3!muller
From: muller@sdcc3.UUCP (Keith Muller)
Newsgroups: net.bugs.uucp
Subject: Re: hung line help needed
Message-ID: <2490@sdcc3.UUCP>
Date: Fri, 23-Nov-84 13:12:18 EST
Article-I.D.: sdcc3.2490
Posted: Fri Nov 23 13:12:18 1984
Date-Received: Sat, 24-Nov-84 05:58:39 EST
References: <449@godot.UUCP> <85@daemon.UUCP> <492@godot.UUCP> <498@astrovax.UUCP>
Distribution: net
Organization: U.C. San Diego, Academic Computer Center
Lines: 29

> 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.
> 

I am not sure that this might be your problem, but I had a similar problem
with the dialer code in 4.2 condevs.c. The following is extracted from a
rlog on my condevs.c.


A problem exisisted in many dialer routines that next_fd was NOT
set to -1 right after a successful open. The routine getnextfd() that
preceeded the open attempts to predict the next file descriptor
to be allocated. The sigalrm handler alarmtr would close the file
descriptor set in next_fd (set by getnextfd). So when the routine
expect timed out during login it called alarmtr, the file was closed
causing a BAD WRITE abort.

What you need to make sure that right after the open call in vadopn()
you have the following:
		/* open call ....*/
		alarm(0); /* cancel time out wait on open */
		next_fd = -1; /* this was missing in many of the dialer code*/


	Keith Muller
	Academic Computer Center
	University of California, San Diego