ignacio / stacktraceplus Goto Github PK

I wanted to get a good trace for a bug in a neovim lua plugin
unfortunately neovim is suppressing the traces, including StackTracePlus's , output.
I wonder if there could be an option to output to a file from with in the script itself?

Hi Ignacio,

maybe I'm doing something wrong but the library doesn't seem to work with LuaJIT for me. I used the simple script from README example:

local STP = require "StackTracePlus"

debug.traceback = STP.stacktrace
function test()
    local s = "this is a string"
    local n = 42
    local t = { foo = "bar" }
    local co = coroutine
    local cr = coroutine.create

    error("an error")
end
test()

When I run the file in LuaJIT I see the default error output:

$ luajit -v
LuaJIT 2.0.2 -- Copyright (C) 2005-2013 Mike Pall. http://luajit.org
$ luajit stptest.lua 
luajit: stptest.lua:11: an error
stack traceback:
    [C]: in function 'error'
    stptest.lua:11: in function 'test'
    stptest.lua:13: in main chunk
    [C]: at 0x00404ce0

However, running it with regular Lua 5.1, it see the pretty output:

$ lua -v
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
$ lua stptest.lua 
lua: stptest.lua:11: an error
Stack Traceback
===============
(2) global C function 'error'
(3) Lua global 'test' at file 'stptest.lua:11'
    Local variables:
     s = string: "this is a string"
     n = number: 42
     t = table: 0xfb5760  {foo:bar}
     co = coroutine module
     cr = C function: 0xfa42e0
(4) main chunk of file 'stptest.lua' at line 13
(5)  C function 'function: 0xfa41a0'

It seems that using stacktraceplus with strict.lua or pl.strict is not working.

As requested. Have some sort of way to retrieve the stack trace in a structure that can be manipulated, serialized, etc.

STP currently does not dump locals of C functions. When debugging those written using the Lua C API, it sometimes happens that the stacks looks different from what I expected. In these cases I would love to use STP to tell me about the stack.

The fix is simple:

--- a/src/StackTracePlus.lua
+++ b/src/StackTracePlus.lua
@@ -355,6 +355,7 @@ Stack Traceback
                        local function_name = m_user_known_functions[info.func] or m_known_functions[info.func] or info.name or tostring(info.func)
                        dumper:add_f("(%d) %s C function '%s'\r\n", level_to_show, info.namewhat, function_name)
                        --dumper:add_f("%s%s = C %s\r\n", prefix, name, (m_known_functions[value] and ("function: " .. m_known_functions[value]) or tostring(value)))
+                       dumper:DumpLocals(level)
                elseif info.what == "tail" then
                        --print("tail")
                        --for k,v in pairs(info) do print(k,v, type(v)) end--print(info.namewhat, info.name)

Let the user configure that somehow.

@ignacio, I really like this library and am using it in production.

The other day there was an incident where a user was trying to upload a large file. This caused an error to be raised in the Lua code... and since StackTracePlus was in use, and the content of the file was in a local variable... it logged the entire contents of the file.

We would like to avoid log entries which are dozens or hundreds of MB long. I am wondering if StackTracePlus could be enhanced to allow setting a maximum string length which will be logged (perhaps also maximum table size/depth would also be good).

If a string is too long, I am thinking it could be printed something like:

"contents contents contents..." (truncated at XYZ bytes)

If you like this idea, I am happy to implement it.

I can't investigate it deeper right now, but there seems to be some edge case probably caused by weird metamethods or references.

I tagged the relevant commit in my host code here.

When building the stack trace, if a value is a table or a userdata with a __tostring metamethod and it throws an error when called, we fail with error in error handling.

The stack trace is not properly generated when an error occurs in a coroutine. It builds the trace for the main thread instead.

STP.stacktrace is not strictly compatible to debug.traceback: It returns two values, instead of one. This creates problems in conjunction with varargs functions and those created through the Lua C API (which will happily consume the additional argument, creating an unexpected stack layout).

Is this something you want to fix?

--- a/src/StackTracePlus.lua
+++ b/src/StackTracePlus.lua
@@ -391,7 +392,7 @@ Stack Traceback
                info = dumper.getinfo(level, "nSlf")
        end

-       return dumper:concat_lines(), original_error
+       return dumper:concat_lines()
 end

 --