lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> When I'm first running my game on Windows, during init it will very very
> rarely assert deep in Lua right after doing a pushclosure(). The assert
> is line 664 in lgc.c:
>   lua_assert(isblack(o) && iswhite(v) && !isdead(g, v) && !isdead(g, o));
> If I skip past that assert, it then asserts once on line 374 of lparser.c:
>   lua_assert(luaG_checkcode(f));
> After that, the game seems to run normally (no more asserts). My
> question is whether these asserts are likely indicative of a deeper
> problem in my code? I've only seen this maybe three times in hundreds of
> runs, though since lua_assert is only enabled in debug builds, if this
> is actually hinting at some kind of random corruption, it would be good
> to know.

Both assertions are not expected to fail. Strangely, they are not
related (that is, I cannot think of one single cause for both to fail,
except for a memory corruption somewhere).  The first one is related to
the garbage collector, something notoriously delicate, so it might be a
Lua bug. But the second is related to the parser; it is unlikely that
you are hitting at two Lua bugs at once.

> As far as I can tell all the code up until that point should be
> deterministic; there's no user input or randomness involved, and there
> is only a single thread that ever accesses Lua. It's in the midst of
> binding a bunch of functions to Lua, calling "require" on the various
> game utility files, and running other various initialization code.

Because the first assert is related to garbage collection, it is highly
sensitive to memory usage. For instance, a difference of one byte
in the length of a temporary file name may change the place of all
following steps of the collector and therefore its entire behavior.

> Since it SEEMS to be OK, my current plan is to leave Lua asserts
> disabled in release code. Let me know if you think should be digging for
> a deeper issue.

It depends on how reliable your game must be. Certainly there is some
deeper issue there, the question is whether it is worth finding it.

-- Roberto