VALIDATE: #{what should be an anonymous object} not in it's parent's #{parent} children. (stunt)

[Tom Dawson]

Afternoon,

Had an interesting issue on a server restart - the startup script spammed an absolute load of entries like:

Sep 13 05:02:35: *** VALIDATE: #64359 not in it's parent's (#45268) children.

...and wouldn't come back p.

As far as I'm aware the objects it's complaining about are/were all anonymous (there were a few different parents involved, but they all appear to be stubs). Unfortunately I couldn't get the server to come back up without actually editing the .db file and adding them as children to their respective parents. This has let me bring the server back up, but there are still some stability issues where things get referenced and cause a panic/segfault - I've tracked this down to something calling parent() on an anonymous object, which presumably doesn't have a parent anymore (yet the server could come back up from this without a "x is in y's child list but doesn't have y as a parent" type error, the wording of which escapes me).

I'm not sure what happened to cause this, which is mildly concerning.

I'm also a little stumped as to what to do to fix this properly. One option is to edit the .db and remove all of the affected objects and put the parent's child list back to empty, but I'm not 100% certain on the database structure and what else I'd need to change beyond just removing the objects.

Another option I looked into was re-parenting all these objects to something different. Seems to work as a test, but actually recycling one will again panic the moo, this time with a "moo: db_properties.cc:903: void dbpriv_fix_properties_after_chparent(Var, Var, Var, Var): Assertion `old_count == me->nval' failed." error.

What I've done is basically batten down the hatches - nyxed a bit of code that tries to call parent() on anonymous objects and removed them from .owned_objects on some people so they can't accidentally be seen easily, but I'd like to find a way to get rid of the fuckers or restore them to their proper status.

Has anyone come across something like this before?

Cheers

[Tim van Dijen]

Hey Tom,

Quite an interesting problem you have there!
Just a few questions:  What version of Stunt are you using? And have you made any changes to it?

Tim

Op 13-9-2016 om 16:30 schreef Tom Dawson:

--
You received this message because you are subscribed to the Google Groups "MOO Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+u...@googlegroups.com.
To post to this group, send email to MOO-...@googlegroups.com.
Visit this group at https://groups.google.com/group/MOO-talk.
For more options, visit https://groups.google.com/d/optout.

[Michael Munson]

This is an interesting problem. As a quick fix I would recommend finding that file object reference in the flat text database and then just either deleting it or clearing its parents. Back up the DB before you try this.

--

You received this message because you are subscribed to the Google Groups "MOO Talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+unsubscribe@googlegroups.com.

[Tom Dawson]

It's 1.8.3 - there may be a few other changes to it though that I'm unsure about. 

We recently switched to unforked checkpoints due to a crippling lack of memory and this was the first reboot since then, but I can't immediately see how that would have caused the problem unless something else crept in at compile time.

Michael may actually know more - I'm not sure he realised who I was from the initial post (hi it's Rain).

[Michael Munson]

LOL. :)

To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+unsubscribe@googlegroups.com.

[Tim van Dijen]

Op 14-9-2016 om 09:57 schreef Tom Dawson:

> It's 1.8.3 - there may be a few other changes to it though that I'm
> unsure about.
>
> We recently switched to unforked checkpoints due to a crippling lack
> of memory and this was the first reboot since then, but I can't
> immediately see how that would have caused the problem unless
> something else crept in at compile time.
>

Well, if you take your backup from before you made the switch you
should be able to reproduce the problem.. Try both forked/unforked
checkpoints and see what happens.. That way we have a clue where to look.

Tim