Re: ihash_add

[Marcus Brinkmann]

On Mon, Aug 20, 2001 at 02:22:30PM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > In general, my plan was to read the whole of ihash.c and ponder it, in case
> > there are any more bugs.  In fact, we know from the proc bug that the hash
> > grows faster then it should: Although the number of processes running at the
> > same time remains constant, the hash table grows (otherwise, the broken
> > seive code wouldn't have been called).  But I don't have much info about it
> > right now.  Part might be due to dead processes that are not reaped.
> 
> I though this was just because of bugs in genpid...

No, I don't think so.  First, I am still observing this behaviour,
and even with the old genpid, there shouldn't be any difference
because the hashing is % ht->size.  size is a prime and the rehash
is so that it should iterate through the whole hash and find any empty
or deleted space if one exists.  (The finite additive group Z_k is
generated by any element != 0 if k is a prime).

We know that at some time the hash grew to about 60000, and tried to grow even
further (crashing in prime generation at this point).  In theory, this should
not happen if there are not so many elements in the pidtable, that means:
an equal number of running or zombie processes.  However, I believe this
has not been the case (I think I verified that reaped childs are removed from
the pidhash correctly).

I have run proc in mtrace, and have seen that the hash grows over time.
The next step is to either write a standalone program that challenges libihash,
or debug proc to see what really happens.

Thanks,
Marcus