[pups] Strange problems on an uPDP 11/53+

[Steven M. Schultz]

Hi --

> Well, strange things are afoot indeed. About the same time, 1 machine...
> they're standing quite near to eachother. Do I hear EMC somewhere?

	Time to increase the shielding around the computer room, eh? ;-)

> Well, the machine had 1.5 MB before it crashed.. It's doubtlessly some
> memory fault, but it *seems* to be a temporal one.

	I do not think it is a memory/hardware problem - that was just a
	guess (not a very good one at that ;)).

> hw.usermem = 313472

	That's fine.

> Should be enough. 'cc' works without problems - only my ps with debug

	What about the standard 'ps' that came with the system?

> info seems to be affected; it might not be a memory issue, but a "ps can't
> determine the right amount of processes"-issue.. 
> I've checked it, and this seems to be the case. Ps thinks that there are
> 0 processes running, and does a 
>  outargs = (struct psout *)calloc(nproc, sizeof(struct psout));

	Ah, ok - malloc() used to actually return a non-NULL pointer when
	presented with a size request of 0.  That was an error and was changed
	(I forget the exact update/patch number).  There were a couple programs
	in the system that relied on the old behaviour and those had to be
	fixed.

> on that. With 'nproc' being 0, this returns a NULL pointer, but doesn't
> mean that the process is out of memory.

	Right, the ENOMEM error was overloaded by malloc().  An argument
	can be made that EINVAL should have been returned instead by malloc()
	if 0 was passed in.

> Having no ps is very annoying; finding back those 4 children spawned
> by a httpd can be a nuisance then. pstat -p works, but it isn't comfortable:)

	Are you are using the traditional 'nlist()' method of reading
	the kernel symbol table to look for 'nproc' and '_proc'?  If so
	is there a permissions problem?  /dev/*mem needs to be group=kmem, mode
	640, the /unix image should be mode 644 and the 'ps' program setgid
	to kmem.   If there is a problem reading the kernel symbol table
	then 'nproc' will remain 0 which is what you're seeing.

	Another way of examining some kernel variables (proc table, file table,
	etc) is with the "sysctl" call.  It's much faster since it doesn't
	have to do a sequential scan of the /unix symbol table.   You can
	look in /usr/src/ucb/w.c at the function 'readpr()' to see how to
	examine the proc table using sysctl.  

	Steve