[DGD] Object finding (this is weird)

[Felix A. Croes]

Shentino <shentino at gmail.com> wrote:

> Ok, now I run into something just plain weird.
>
> While building my object database at initd time, I first sweep the
> filesystem with the get_dir to find out all the blueprints and libs,
> then I sweep through objregd to get the clones.  I don't delete any
> source files, or destruct or recompile any objects.
>
> I put the two lists together and eliminate the duplicate names and I
> get a very weird result...
>
> The number of objects my objectd found at boot is an exact match for
> the status() kfun, and the index numbers (both at the end of the
> object name for clones, and the status O_INDEX for nonclones) are all
> unique and contiguous...
>
> ...but according to the Klib's resource manager I missed 3 objects.
> Klib's object count is also 3 higher than what the status kfun is
> telling me exist.
>
> Why is the Klib 3 over both my own count and DGD's count?

It is normal for things to be the other way: the resource manager and
your object manager do not keep track of connection objects, and
the number of objects according to status() is therefore higher by
the number of connections to the mud.  The standard wiztool adds
the number of connections to the number of objects reported by
the resource manager when it displays that resource, to arrive at
the overall correct number.

So when nothing is destructed or recompiled,

    rsrc::query_rsrc("objects")[0] + sizeof(access::query_connections())
    ==
    status()[ST_NOBJECTS]

For the resource manager's count to be higher than the number reported
by status() would have to be a bug in the kernel library, unless you
are manually manipulating the objects resource, which I assume is not
the case.

Since you can compare the number reported by the resource manager and
by status() at every step, it should be possible to narrow down where
the anomaly occurs.

Regards,
Dworkin