Thanks for the clarifications & design advice. I really appreciate your feedback.
Mike Pall wrote:
But they are not set up to handle intermediate states with dangling pointers, updated values only held in registers and anything else that might occur in a crash scenario.
Good point.Given that inconsistencies are expected in a crash, is there a systematic approach to enumerating various permutations of inconsistent VM state, or is this a matter of creativity & trial-and-error / evolution over time? Maybe a form of "core dump fuzz testing" would help?
Is there a simpler way to adapt and reuse the VM internal structure walking routines?Not without rewriting large parts of it. And this won't cover core dumps of cross-compiled VMs, either.
Ok, I'm convinced. This particular flavor of traversal is indeed better handled with specialized code outside the LuaJIT core.
I have an idea regarding cross-compiled VM postmortem debugging, explained near the bottom of this reply.
https://github.com/agentzh/nginx-systemtap-toolkit/blob/master/ngx-sample-lua-btIf you strip it down to the parts that deal only with LuaJIT, you'll see it's really not that much code.
You're right, the LuaJIT bits are not much code at all. The relevant VM state is much simpler than I expected - very nice.
I'm gonna adapt this code to my experiment.
One post-mortem debugging problem that trips up every Lua / LuaJIT debugger I've seen (that one included) is locating the root lua_State'sWell, you need a valid C stack backtrace, anyway. Otherwise you can't handle compiled traces. From there it shouldn't be too hard to get a valid lua_State.
I'm not familiar with this issue. Is this similar to the difficulty of obtaining a stack trace with FPO enabled? Can you elaborate or point to docs that explain?
Another option is to store the lua_State yourself to a known fixed location, e.g. in thread-local storage.
I'm thinking this can be implemented as a small reusable C library that makes a project "core dump debugger friendly". The library wraps the Lua state creation / destruction APIs, tracks active VM states, and exposes VM instances at a well-known location (as you say, in TLS).
To enable cross-compiled core dump debugging, this library also exposes VM data structure metadata [1]. For example, struct / union fields and their types / offsets / sizes. There may of course be other cross-compilation / portability problems for such a debugger.
The whole thing is basically a set of policies that a project and the debugger follow, and the library would handle the details of adhering to those policies.
Note:[1] by whatever means works best - export a symbol pointing at static data blobs inside DLL / EXE, external debug metadata file, smoke signals, all of the above, etc. This is of course transparent to users of the "postmortem debug support library".
