[pups] Strange problems on an uPDP 11/53+
Steven M. Schultz
sms at moe.2bsd.com
Wed Feb 7 02:36:03 AEST 2001
> 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
> 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
> 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.
More information about the TUHS