Serialization error shown as "Error in stack information"

[nneesshh]

Hi @pkulchenko,
When I debug an app under win10，the app will lost responding for some code.
It seem's like the debugger "stack" command is in dead waiting for response from app.
The error messgae see below:

[192.168.1.110:49938] Debugger sent (command): stack -- {comment = false, maxlength = false, maxlevel = 3, maxnum = 128, metatostring = false, nocode = true, numformat = "%.16g"}
Error in stack information: [string "do local _={{{"dealWithPVEStart","model/Handl..."]:1: attempt to index a number value
[192.168.1.110:49938] Debugger received (file, line, err): nil nil [string "do local _={{{"dealWithPVEStart","model/Handl..."]:1: attempt to index a number value
[192.168.1.110:49938] Debugger sent (command): run
Paused at file model/help/dataconvert.lua line 1210
[192.168.1.110:49938] Debugger received (file, line, err): model/help/dataconvert.lua 1210 nil
[192.168.1.110:49938] Debugger sent (command): stack -- {comment = false, maxlength = false, maxlevel = 3, maxnum = 128, metatostring = false, nocode = true, numformat = "%.16g"}

What may trigger the "Error in stack information"? filer name uppercase or lowercase problem? or some setting is overflow?

[pkulchenko]

What may trigger the "Error in stack information"? filer name uppercase or lowercase problem? or some setting is overflow?

This is most likely is caused by the issue in the serialized content (or a bug in serializer).

Can you apply the following patch, which should capture the serialized content (the line numbers may be a bit off, but look at the context lines):

diff --git a/lualibs/mobdebug/mobdebug.lua b/lualibs/mobdebug/mobdebug.lua
index 2e20e72a..8c9b70e1 100644
--- a/lualibs/mobdebug/mobdebug.lua
+++ b/lualibs/mobdebug/mobdebug.lua
@@ -1506,6 +1506,7 @@ local function handle(params, client, options)
     local _, _, status, res = string.find(resp, "^(%d+)%s+%w+%s+(.+)%s*$")
     if status == "200" then
       local func, err = loadstring(res)
+print(res)
       if func == nil then
         print("Error in stack information: " .. err)
         return nil, nil, err

Try running through the same steps again and you should see the serialized content in the Output window.

Can you share the code snippet it happens on? Can you reduce it down to a small fragment?

[nneesshh]

Hi @pkulchenko , I made a demo: zbslua.zip to reproduce the problem
zbslua.zip

See "test_pb.lua", line 17 "tmsg1:ParseFromString(pbdata)", HOPE it will help.

[pkulchenko]

@nneesshh, can you run it with the mobdebug change I showed earlier and include the output from print(res) command? If it's too large, you can attach it to your comment.

[nneesshh]

test_stack.zip

My code snippet:
local _, _, status, res = string.find(resp, "^(%d+)%s+%w+%s+(.+)%s*$")
if status == "200" then
local func, err = loadstring(res)
if func == nil then
print("Error in stack information: " .. err)
return nil, nil, err
end
local ok, stack = pcall(func)
if not ok then
print(res)
print("================================")
print("Error in stack information: " .. stack)
return nil, nil, stack
end
for _,frame in ipairs(stack) do
print(mobdebug.line(frame[1], {comment = false}))
end
return stack

[pkulchenko]

It seems to fails on the following fragment in the serialized code:

_[1][2].tmsg1[1]._fields[__._table1][__._table1]=0;
_[1][2].tmsg1[1]._fields[__._table1][__._table1]=1;
_[1][2].tmsg1[1]._fields[__._table1]._listener=_[1][2].tmsg1[1]._fields[__._table1][__._table1][__._table1];

The code assigns a numerical value to _[1][2].tmsg1[1]._fields[__._table1][__._table1] and then attempts to index it. It's not clear to me yet why this happens and it's also not clear what the point is of assigning two different values to the same table element (this also happens in several places).

There does seem to be an issue with serializing this data structure that you have, but due to its complexity I can't yet figure out what exactly is going wrong here.

It doesn't seem to be related to protobuf, but is rather related to your PVE library. Any idea why it recursively references the same table in this fragment:

__._table1.PVEBattleResponse=__._table1;
__._table1._concrete_class=__._table1;
__._table1.containing_type=__._table1;
__._table1[2]=__._table1;
_[1][2].tmsg1[1]._fields[__._table1]={_listener_for_children={dirty=true,_parent_message=nil,__mode="v"},_fields={},_cached_byte_size_dirty=true,_listener=nil,_is_present_in_parent=true,_cached_byte_size=0};
_[1][2].tmsg1[1]._fields[__._table1]._parent_message=_[1][2].tmsg1[1]._fields[__._table1];
_[1][2].tmsg1[1]._fields[__._table1][__._table1]={_listener_for_children={dirty=true,_parent_message=nil,__mode="v"},_fields={},_cached_byte_size_dirty=true,_listener=nil,_is_present_in_parent=true,_cached_byte_size=0};
_[1][2].tmsg1[1]._fields[__._table1][__._table1]._parent_message=_[1][2].tmsg1[1]._fields[__._table1][__._table1];

Does the structure matches what you'd expect? Can you reproduce the same issue if you comment out ParseFromString call from your test_pb.lua script?

[nneesshh]

Hi, @pkulchenko,
As I known, "__._table1" is a message field key, and "_[1][2].tmsg1[1]._fields[__._table1]" is the filed value,
But the "_[1][2].tmsg1[1]._fields[__._table1][__._table1]" is really says "value[key]", it should not exist at all.

So where is the "_[1][2].tmsg1[1]._fields[__._table1][__._table1]=0;" serialized from? I don't known what it is describing.

Maybe the code of retrieving stack from remote can solve the question, could you show me a simulate code snippet for how to retrieve stack locally?

PS: if I comment out ParseFromString call, the error disappear. Only message after parsed produce the error.

[pkulchenko]

@nneesshh, can you try the following patch:

diff --git a/lualibs/mobdebug/mobdebug.lua b/lualibs/mobdebug/mobdebug.lua
index 2e20e72a..3714c6f1 100644
--- a/lualibs/mobdebug/mobdebug.lua
+++ b/lualibs/mobdebug/mobdebug.lua
@@ -130,7 +130,7 @@ end
 local function q(s) return string.gsub(s, '([%(%)%.%%%+%-%*%?%[%^%$%]])','%%%1') end
 
 local serpent = (function() ---- include Serpent module for serialization
-local n, v = "serpent", "0.301" -- (C) 2012-17 Paul Kulchenko; MIT License
+local n, v = "serpent", "0.302" -- (C) 2012-18 Paul Kulchenko; MIT License
 local c, d = "Paul Kulchenko", "Lua serializer and pretty printer"
 local snum = {[tostring(1/0)]='1/0 --[[math.huge]]',[tostring(-1/0)]='-1/0 --[[-math.huge]]',[tostring(0/0)]='0/0'}
 local badtype = {thread = true, userdata = true, cdata = true}
@@ -221,7 +221,7 @@ local function s(t, opts)
           local path = seen[t]..'['..tostring(seen[key] or globals[key] or gensym(key))..']'
           sref[#sref] = path..space..'='..space..tostring(seen[value] or val2str(value,nil,indent,path))
         else
-          out[#out+1] = val2str(value,key,indent,insref,seen[t],plainindex,level+1)
+          out[#out+1] = val2str(value,key,indent,nil,seen[t],plainindex,level+1)
           if maxlen then
             maxlen = maxlen - #out[#out]
             if maxlen < 0 then break end

There was a fix submitted for a serialization issue and I've been wondering if it may help in this case as well.

[nneesshh]

Hi, @pkulchenko, after modified two lines
1、+local n, v = "serpent", "0.302" -- (C) 2012-18 Paul Kulchenko; MIT License
2、+ out[#out+1] = val2str(value,key,indent,nil,seen[t],plainindex,level+1)

The "Error in stack information" error disappeared.

But the lost responding problem still exists. I think it is the bug of __tostring() meta method of userdata.
If the __tostring() method dead loop, the debugger lost responding. I encountered the same problem in another lua debugger plugin of vscode some days ago.

I think this issue can be closed, thanks your great work.

[pkulchenko]

Sounds good; thank you for the update.

You are right, if __tostring is looping, there is not much that can be done in the debugger.