lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I brought this up on this list a few years ago, and I still find this issue
bugs me every now and then. Just writing this to the list once more to see if
and how other people are dealing with this:

I use Lua for various applications on a number of embedded devices, and
one of the important methods of finding and solving problems in the
field is the collection of log files, including Lua stack traces.

Every now and then I receive log files with stack traces which have parts of
them 'lost' because of tail calls in the call stack. For example:

05:39:50 wrn | Error: cannot resume non-suspended coroutine
05:39:50 wrn | stack traceback:
05:39:50 wrn |   ./core/co.lua:13: in function <./core/co.lua:9>
05:39:50 wrn |   (...tail calls...)
05:39:50 wrn |   leaflets/atport/atport.lua:187: in function 'close'

In the code there are several possible paths that could lead to this particular
point, but the stack trace is not able to tell me which one.

I find this behaviour perfectly acceptable, tail recursion is a valuable part
of the language, and I do understand the implications.

Personally I would be very happy with a way to enable and disable tail calls at
run time, so an application could be switched into 'debug mode' and not use
tail calls/returns. I guess this will cause some overhead in the vm opcode
handling though.

For debugging, I usually have separate Lua version around from which I simple
replaced the OP_TAILCALL part from the vm by a regular OP_CALL. Using this Lua
binary for reproducing the problem results in full stack traces, which is
usually enough to pinpoint the problem. The problem is that this requires
restarting the application, which often interferes with debugging because the
application state from the time of the error is reset.

Are there other people out there who are having issues with tail call stack
traces, and if so, how dow you handle this in real life debugging?