Re: [ANN] StackTracePlus 0.1.0

[Hisham <h@...>]

On 27 September 2013 15:43, Rena <hyperhacker@gmail.com> wrote:
> On 2013-09-27 2:40 PM, "Hisham" <h@hisham.hm> wrote:
>>
>> On 27 September 2013 10:04, Matthew Wild <mwild1@gmail.com> wrote:
>> > On 27 September 2013 11:55, Jerome Vuarand <jerome.vuarand@gmail.com>
>> > wrote:
>> >> 2013/9/23 Ignacio Burgueño <iburgueno@gmail.com>:
>> >>> I'd like to announce StackTracePlus.
>> >>>
>> >>> https://github.com/ignacio/StackTracePlus
>> >>
>> >> Timing is interesting, I worked on something similar in the last few
>> >> weeks.
>> >
>> > I also implemented something like this for Prosody. The primary
>> > purpose was for easier debugging, since stack traces are often the
>> > best we get to work with. Increasing their verbosity, and also their
>> > clarity, was important as I found the default stack traces too dense
>> > to read at a glance. Plus when switching between languages I found it
>> > impossible to remember whether I should be looking at the top or
>> > bottom of the listing (hi Python!).
>> >
>> > I also drew marker lines where the stack crossed between different
>> > modules, or between C and Lua.
>> >
>> > Since I added colour as well, the best explanation is a screenshot:
>> > https://matthewwild.co.uk/uploads/util_debug.png
>>
>> As a fan of colorful terminal output... wow :)
>>
>> Since we're on the topic of stack traces... tail calls always bug me
>> (no pun intended!) in stack traces. One very little thing I did that
>> improved my life a lot was to build a modified version of the Lua
>> interpreter which does not emit tail calls (it's a tiny change, just
>> search for OP_TAILCALL in the appropriate place in Lua 5.1 or 5.2, I
>> did it for both). When I'm reproducing a bug that has tail calls in
>> it, it's often faster to re-run my script with `./lua-5.2-no-tailcalls
>> script.lua` and see the whole stack trace than to try to figure out
>> the missing steps. Of course it can't be used all the time or else
>> tail-recursive functions will overflow, but as a side tool for
>> debugging, it's really handy. It's something that, after I came up
>> with it, it made me think "why didn't I do this years ago?".
>>
>> -- Hisham
>>
>
> I've often wished for a way to disable tail calls, perhaps through the debug
> library, in order to get better stack traces. Do you have a patch for your
> modified version?

I didn't even have the patches with me anymore, but if I recall
correctly it was only this one-line change:

Lua 5.1.5: https://gist.github.com/hishamhm/6735243

diff -ur lua-5.1.5/src/lparser.c lua-5.1.5-notailcalls/src/lparser.c
--- lua-5.1.5/src/lparser.c    2011-10-21 17:31:42.000000000 -0200
+++ lua-5.1.5-notailcalls/src/lparser.c    2013-09-27 17:44:56.000000000 -0300
@@ -1248,7 +1248,7 @@
     if (hasmultret(e.k)) {
       luaK_setmultret(fs, &e);
       if (e.k == VCALL && nret == 1) {  /* tail call? */
-        SET_OPCODE(getcode(fs,&e), OP_TAILCALL);
+        SET_OPCODE(getcode(fs,&e), OP_CALL);
         lua_assert(GETARG_A(getcode(fs,&e)) == fs->nactvar);
       }
       first = fs->nactvar;

Lua 5.2.2: https://gist.github.com/hishamhm/6735265

diff -ur lua-5.2.2/src/lparser.c lua-5.2.2-notailcalls/src/lparser.c
--- lua-5.2.2/src/lparser.c    2013-02-06 11:37:39.000000000 -0200
+++ lua-5.2.2-notailcalls/src/lparser.c    2013-09-27 18:04:20.000000000 -0300
@@ -1505,7 +1505,7 @@
     if (hasmultret(e.k)) {
       luaK_setmultret(fs, &e);
       if (e.k == VCALL && nret == 1) {  /* tail call? */
-        SET_OPCODE(getcode(fs,&e), OP_TAILCALL);
+        SET_OPCODE(getcode(fs,&e), OP_CALL);
         lua_assert(GETARG_A(getcode(fs,&e)) == fs->nactvar);
       }
       first = fs->nactvar;

-- Hisham