3 ms·
I do most of my work in Lua. So the GDB traces will be to the major Lua routines. I'm going to assume the ports of microPython will have the same problem. An
by AstroJetson 11y ago
I do most of my work in Lua. So the GDB traces will be to the major Lua routines. I'm going to assume the ports of microPython will have the same problem. Any suggestions for those implementations?
- devbug 11y agoImmediate 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.