4.1c subgroup?

jim at mcvax.UUCP jim at mcvax.UUCP
Thu Jun 30 14:04:23 AEST 1983


Yes, I think we could get by with using net.bugs.4bsd,
there isn't much traffic on it (we don't get much anyway).

As a starter, has anyone tried to bind() to a socket in the
UNIX domain? Fun, isn't it? The exact fix depends on what you
think the format of an address in the UNIX domain should be,
whether it should have "family" specifier or just the
pathname (I plump for the latter). And isn't 14 characters a
bit short for the FULL pathname? But anyway, you need to do
a check on whether namei() sets u.u_error in unp_bind() in
uipc_usrreq.c, otherwise maknode() tries to do something with
the illegal value set into u.u_pdir by namei(), and SPLAT!

So I fixed that, and the system decided to go into a tight loop
if you try to interrupt a process while it is listen()ing
but has had no connect()ions yet. I know where it is looping,
but haven't got round to fixing it yet. To save time we changed
the application program to use the TCP/IP domain, and, what do 
you know, in the same state as above, we got "panic: tcp_output"!
A fix for this one is to add a 
	case TCPS_CLOSED:
tcp_usrclosed() in tcp_usrreq.c before the line 
		tp = tcp_close();
(This bug occured, though the code is not the same, in 4.1A too).

These things are not so easy to track down when /etc/savecore
continues to say "dumping 0 bytes of core in vmcore.7" on reboot.
Anyone have a fix for that?

Do we all have these bugs? Are we all running the same version of
4.1C (ours dates from beginning of April)?

Not afraid to let the hedgehogs call him Jungle Jim,

	Jim McKie	....decvax!mcvax!jim
			...philabs!mcvax!jim



More information about the Comp.bugs.4bsd.ucb-fixes mailing list