/std/user/user.c clone not dested for users relogging in after link-dead

[Richard Thomas Harrison]

When a user goes link-dead, if they re-connect before being automatically dested then a second clone of /std/user/user.c is made pointing to the original body. This leaves 2 clones of /std/user/user.c both pointing to the same mobile body.

If this happens again then another clone is made leading to multiple clones of /std/user/user.c all pointing to one mobile body.

Possible fix: A cleanup object that runs every-so-often to destruct orphan clones.

[Cody A.W. Somerville (cody-somerville)]

My recommended solution would be to simply to either:

a) Destroy the old user (aka connection) object on reconnect; or
b) Reuse the old user (aka connection) object.

However, some sort of cleanup system wouldn't hurt either but is more of a new feature (*cough*spec it*cough*) than a solution to this bug.

[Richard Thomas Harrison (harrison-rt)]

Well I have implemented a possible fix on the dev mud and turned off Igor's cleanup code.

I''ll let it run a few days and see if it works. If it does I'll add it to the main branch.

One thing I did notice with /adm/obj/login.c is that if the object exits and destructs due to a lockdown, ban or user taking too long to login, then the user object that has been created by login.c will still be loaded.

[Richard Thomas Harrison (harrison-rt)]

> However, some sort of cleanup system wouldn't hurt either but is more of a new feature
> (*cough*spec it*cough*) than a solution to this bug.

kk. :)

I'll leave it till after I have most of the leaks knocked into shape though. That way it can be used to cleanup after sloppy builders leaving objects loaded and orphaned. ;)

[Cody A.W. Somerville (cody-somerville)]

Does this affect lpuni-final? If so, please open a task for it.