How to dump full Lua VM state?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

How to dump full Lua VM state?

Mateusz Czaplinski
I want do dump the *full* VM state. Do I have to traverse all the
pointers, tables, etc. in lua_State (lstate.h) on a case-by-case
basis, or is there some easier way? Or do you know if there's maybe
some code for that already somewhere?

Could I make any assumptions which could simplify the dumping? For
example, maybe the blocks/pointers used in the struct are allocated
sequentially from some contiguous memory block, or something?

It would be probably enough for me to dump the state as binary, not
human readable. My higher level problem is that I want to find out
what's going wrong when building+running Lua on one somewhat esoteric
compiler + custom stdlib (the latter is the most probable culprit) --
I'd like to compare its VM state evolution with that of a regular gcc
x86 build.

I'd be grateful for help,
Thanks,
/Mateusz Czapliński.

Reply | Threaded
Open this post in threaded view
|

Re: How to dump full Lua VM state?

Fabien-3

On Mon, Oct 29, 2012 at 2:17 PM, Mateusz Czaplinski <[hidden email]> wrote:
I want do dump the *full* VM state.

The meaning of "dumping the whole Lua state" is not as unambiguous as it seems at first, think e.g. of userdata. The best tool to hibernate and restore a whole Lua state is Pluto: it can be tuned to what you exactly mean by "full state". It takes a bit of RTFMing, though.

Reply | Threaded
Open this post in threaded view
|

Re: How to dump full Lua VM state?

Mateusz Czaplinski
On Tue, Oct 30, 2012 at 9:41 AM, Fabien <[hidden email]> wrote:
> On Mon, Oct 29, 2012 at 2:17 PM, Mateusz Czaplinski <[hidden email]>
> wrote:
>>
>> I want do dump the *full* VM state.
>
> The meaning of "dumping the whole Lua state" is not as unambiguous as it
> seems at first, think e.g. of userdata. The best tool to hibernate and
> restore a whole Lua state is Pluto: it can be tuned to what you exactly mean
> by "full state". It takes a bit of RTFMing, though.

I did some more reading of the list archives, after some better
keywords occured to me ("lua_State", "snapshot", "save"), and I have
some ideas for now. (As to userdata, I'm not interested; as I wrote in
the original message, my usecase is not saving/loading a game, but
dumping internals for tracking some supposed corruption of data.) So,
I'm planning to intercept lua_Alloc, to track all allocations on a
linked list (plus preinitialize memory with 0 or a pattern), and then
hexdump a snapshot of the tracked areas of memory after each VM
instruction (via Lua hooks). What I'm not sure about, is: how much
signal to noise will be there (but this might be easier to wade
through if I use the preinitialization pattern), whether this won't be
too big to track reasonably (but a diff tool might solve that), and if
there won't be some differences in memory layout (but this should be
solvable by tweaks in luaconf.h, I must hope).

As to Pluto, I suppose it's aimed at a well behaving VM, so I suspect
it might not help me with monitoring a buggy one.

/Mateusz.