Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watmath.UUCP
Path: utzoo!watmath!arwhite
From: arwhite@watmath.UUCP (Alex White)
Newsgroups: net.bugs.4bsd
Subject: Panic in soqremque from sonewconn
Message-ID: <6928@watmath.UUCP>
Date: Fri, 17-Feb-84 03:18:55 EST
Article-I.D.: watmath.6928
Posted: Fri Feb 17 03:18:55 1984
Date-Received: Sat, 18-Feb-84 01:34:13 EST
Organization: U of Waterloo, Ontario
Lines: 24

Subject: in_pcbdetach does a sofree
Index:	/sys/netinet/in_pcb.c 4.2BSD

Description:
	System dies with a panic from a garbage pointer in soqremque called
	from sonewconn.
	What happens is that sonewconn, calls tcp_usrreq which calls
	tcp_attach, this calls in_pcballoc which succeeds, but then
	tcp_newtcpcb fails due to lack of mbufs.  tcp_attach hence
	calls in_pcbdetach to clean up.  in_pcbdetach unfortunately
	invokes sofree which releases the socket itself.  we then
	return back up to sonewconn.  Sonewconn now tries to clean up
	and release the socket itself; it calls soqremq with the socket
	which now has a zero pointer for so_head and craps out.
	Superficial examination of code as in udp_usrreq, PRU_ABORT
	shows that it invokes in_pcbdetach and then itself calls sofree
	which was done in in_pcbdetach!
Repeat-By:
	Run out of mbuf's.  If you don't crash of panic: exit: m_getclr
	first (I have a fix for that one...) I suppose its probable
	that you'll hit this after a while...
	How to run out of mbuf's is another bug, which I haven't tracked
	down yet - but I suspect that it has something to do with
	unix domain ipc being done by students....