4 ms·
Immediate thoughts go to `debug.traceback` (via xpcall). You're on your own when it comes to Lua<=>C boundaries, however. Now, if you're talking about _manually
by devbug 11y ago
Immediate thoughts go to `debug.traceback` (via xpcall). You're on your own when it comes to Lua<=>C boundaries, however. Now, if you're talking about _manually_ walking the stack... this will point you in the right direction: http://zeuxcg.org/2010/11/07/lua-callstack-with-c-debugger/ http://zeuxcg.org/2010/11/07/lua-callstack-with-c-debugger/
- AstroJetson 11y agoThanks for the hints. I'll need to get to the lab to see how well they work in the ESP8266 environment, that would be a huge bonus win.
- devbug 11y agoHappy to help. To expand upon my 4am ramblings: There's two ways your code is going to fail, (a) Your Lua is going to die in a pcall (or friends); or (b) Your C/C++ (or similar) code has its front fall off. In the former case, you just wrap with an xpcall and append your Lua callstack to your C++ callstack. Nothing fancy. You can of course go further, using lua_Debug to get the value of upvals and all that jazz. However, in the latter case you have no guarantee that your application is in a sane state; you have no (solid) assumption that you can go the lua_Debug route, say from a segfault handler. You'll have to walk the callstack, and when you hit lua_whatever, prod internal state. Both methods are really helpful. Say you're writing a game engine, knowing how to reproduce a catastrophic failure with a small Lua snippet, closes the feedback loop and make debugging a hell of a lot easier. There's definitely a product and SaaS around this (much more expanded), with a Gitlab or Sentry business model.