Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!uccba!ucunix.san.uc.edu!rainwatr
From: rainwatr@ucunix.san.uc.edu (Don Rainwater)
Newsgroups: comp.unix.ultrix
Subject: Re: ultrix 4.0 dbx
Message-ID: <1991Jan23.182707.5251@ucunix.san.uc.edu>
Date: 23 Jan 91 18:27:07 GMT
References: <1991Jan15.145308.1436@jarvis.csri.toronto.edu> <10166@pasteur.Berkeley.EDU> <1991Jan13.204300.20332@cimage.com> <1875@riscy.enet.dec.com> <1991Jan21.185205.26837@jarvis.csri.toronto.edu>
Sender: Don.Rainwater@UC.Edu
Reply-To: Don.Rainwater@UC.Edu
Organization: University of Cincinnati
Lines: 17


	dbx also has the ability to crash Ultrix 4.0 (maybe this has already
been mentioned here).  We had a user who was writing a program to open a
socket and listen to it.  When stepping thru this program with dbx, the
socket_accept statement appears to block, so we interrupt it and quit
from dbx - BOOM, down goes the system.

	This is apparently caused by Ultrix trying to deallocate some
resource (I want to say file pointers, but I don't remember for sure) that
has it doesn't really have (or something like that).  This occurs on
both VAX Ultrix 4.0 and RISC Ultrix 4.0.

	This problem appears to be fixed in Ultrix 4.1.
-- 
Don Rainwater, Systems Manager, Univ. of Cincinnati Computer Center
Don.Rainwater@UC.Edu			rainwatr@ucunix.san.uc.edu
rainwatr@ucbeh.bitnet			...!uccba!ucunix!rainwatr