[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: How to dump full Lua VM state?
- From: Mateusz Czaplinski <czapkofan@...>
- Date: Tue, 30 Oct 2012 20:21:11 +0100
On Tue, Oct 30, 2012 at 9:41 AM, Fabien <fleutot+lua@gmail.com> wrote:
> On Mon, Oct 29, 2012 at 2:17 PM, Mateusz Czaplinski <czapkofan@gmail.com>
> 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.