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