Re: lua 5.2 debug.traceback & stripped chunks

[liam mail <liam.list@...>]

On 30 October 2011 14:14, Ashwin Hirschi <lua-l@reflexis.com> wrote:
>
> It looks like there's a problem in the Lua 5.2 beta when debug.traceback
> encounters a chunk with its debug info stripped.
>
> Here are the steps to reproduce it, using 2 simple scripts:
>
>
> === kick.lua ===
>
> print "kick..."
> dofile "start.lua"
>
>
> === start.lua ===
>
> print "starting..."
> print(debug.traceback())
> print "done."
>
>
> === Scenario #1 : non-compiled ===
>
> Running
>
>        lua kick.lua --> all's well
>
> produces output:
>
>        kick...
>        starting...
>        stack traceback:
>                start.lua:3: in main chunk
>                [C]: in function 'dofile'
>                kick.lua:3: in main chunk
>                [C]: in ?
>        done.
>
>
> === Scenario #2 : compiled ===
>
> Running
>
>        luac -o kick.lc kick.lua
>        lua kick.lc --> all's well
>
> produces the exact same output as scenario 1.
>
>
> === Scenario #3 : compiled & stripped  ===
>
> Running
>
>        luac -s -o kick.lc kick.lua
>        lua kick.lc --> oops...
>
> produces only:
>
>        kick...
>        starting...
>
> and then aborts.
>
>
> Can anyone confirm my findings? Thanks.
>
> Ashwin.
>
>

Yes this can be confirmed. Whilst I would not expect anything
meaningful to be returned by debug* calls with debug information
stripped it really should not seg fault. It would seem the reason (or
at least one of the reasons) is that OP_GETTABUP is not counting on
there being no name and therefore the path which uses getstr is
returning an invalid pointer (which is not NULL) which is then used in
strcmp call causing the seg fault.[1]


[1] https://bitbucket.org/liamdevine/lua-5.2/src/5a7f36ca867d/lua/src/ldebug.c#cl-349