How to navigate invalid reference errors?

[fnuecke]

How to navigate invalid reference errors?

[fnuecke]

Hmm, that's pretty odd indeed. IIRC those should indeed only pop up if something goes wrong internally.

I did recreate a structure generating a path like the one you posted, and that worked fine, so I'd have to guess it's some weird interaction somewhere. Assuming it's a bug, there are a few things you could do to help me track it down:

• Run an eris.unpersist directly after eris.persist, just to check if that already errors (which it should, otherwise I'd lean towards storage error / difference in environment).
• See if it happens all the time for a 'broken' save state, or if the unpersist can succeed/it's random.
• When it happens again, send me the saved state, and ideally a dumbed down version of the perms table (with mocks instead of the real values), or at least a description of what it contains so i can relatively easily re-create it myself. Then I can try to reproduce it and do some more in-depth testing.

Thanks!

[krisr]

Thanks for the quick reply. I'll dig deeper into this and see if I can create a dumbed down version that you can re-create. I'll get back to you soon.

[krisr]

Ok, I was able to reduce this to a much simpler test case that fails for you:

local c = {
  attribute = 1,
  observers = {}
}

local o = {
  inner = {}
}
o.inner.foo = {
  bar = function()
    return c.attribute
  end
}
table.insert(c.observers, o)
setmetatable(o, {
  __persist = function(old)
    local inner = old.inner
    return function()
      return {inner = inner}
    end
  end
})
eris.unpersist({}, eris.persist({}, o))

[fnuecke]

Brilliant, thanks! I'm happy to report this is not a bug ;-)

This is indeed a special case that cannot be persisted, and a very indirect variant of that scenario at that. It's basically what's described in the special persistence section of the readme in the last quote:

It is important that the fixup closure returned not reference the original table directly, as that table would again be persisted as an upvalue, leading to an infinite loop.

Which it - indirectly - does, via the upvalue. When simplified a lot more the above boils down to this:

local a
a = {
  function() -- this has a as an upvalue...
    return a.b
  end
}
setmetatable(a, {
  __persist = function(t)
    local value = t[1] -- so this has an indirect reference to a
    return function()
      return {value}
    end
  end
})
eris.unpersist(eris.persist(a))

I'll see if I can make it produce a better error message, though.

[krisr]

Awesome! Thanks for taking the time to dig into this with me. A different error message would be helpful.

[krisr]

Thinking more about this, I'm not sure there is a clean work around. Am I correct in thinking that this is something that a library like eris could handle directly? If so, I may be willing to give it a shot at some point.

[fnuecke]

Well, I imagine for tables it'd be feasible by "pre-generating" the the table, and passing it to the closure that should restore the table, instead of having that return a new table. It'd not even be necessarily breaking compatibility, if it still had to return the table (as it is now). For userdata that wouldn't work, though...