# Incorrect Stacks Return

[Ferix9288]

Stack Nesting - Issue

Hey @edolphin-ydf ! Just discovered another issue. For now, hoping you can help me out but if you don't have the bandwidth, I can dig even more and hopefully fix myself. No pressure or worries at all.

Currently, there's an issue where the Stacks returned for nested calls return incorrectly. For example, here's my sample lua script I ran:

function call1(a)
    return call2(a)
end

function call2(b)
    return call3(b)
end

function call3(c)
    return c
end

package.cpath = package.cpath .. ";/Users/fli/.vscode/extensions/tangzx.emmylua-0.3.49/debugger/emmy/mac/emmy_core.dylib"
local dbg = require("emmy_core")
dbg.tcpConnect("localhost", 9966)

local hello = call1(10)
print(hello)

However, here's the payload given back from Debugger when I set a breakpoint at call3:

{
  "cmd": 13,
  "stacks": [
    {
      "level": 0,
      "file": "",
      "functionName": "(anonymous)",
      "line": -1,
      "localVariables": [],
      "upvalueVariables": []
    },
    {
      "level": 1,
      "file": "test.lua",
      "functionName": "<test.lua:9>",
      "line": 10,
      "localVariables": [
        {
          "name": "c",
          "nameType": 4,
          "value": "10",
          "valueType": 3,
          "valueTypeName": "number",
          "children": null
        }
      ],
      "upvalueVariables": []
    },
    {
      "level": 2,
      "file": "test.lua",
      "functionName": "main chunk",
      "line": 17,
      "localVariables": [
        {
          "name": "dbg",
          "nameType": 4,
          "value": "",
          "valueType": 5,
          "valueTypeName": "table",
          "children": [
            {
              "name": "tcpConnect",
              "nameType": 4,
              "value": "function: 0xc000180fc0",
              "valueType": 6,
              "valueTypeName": "function",
              "children": null
            }
          ]
        }
      ],
      "upvalueVariables": []
    },
    {
      "level": 3,
      "file": "test.lua",
      "functionName": "main chunk",
      "line": 17,
      "localVariables": [
        {
          "name": "dbg",
          "nameType": 4,
          "value": "",
          "valueType": 5,
          "valueTypeName": "table",
          "children": [
            {
              "name": "tcpConnect",
              "nameType": 4,
              "value": "function: 0xc000180fc0",
              "valueType": 6,
              "valueTypeName": "function",
              "children": null
            }
          ]
        }
      ],
      "upvalueVariables": []
    },
    {
      "level": 4,
      "file": "test.lua",
      "functionName": "main chunk",
      "line": 17,
      "localVariables": [
        {
          "name": "dbg",
          "nameType": 4,
          "value": "",
          "valueType": 5,
          "valueTypeName": "table",
          "children": [
            {
              "name": "tcpConnect",
              "nameType": 4,
              "value": "function: 0xc000180fc0",
              "valueType": 6,
              "valueTypeName": "function",
              "children": null
            }
          ]
        }
      ],
      "upvalueVariables": []
    }
  ]
}

Note that stacks 2-4 all basically return the same frame which is incorrect. My expectation is that it should return the localized stack for call1, call2, etc.

To me, when I inspected the code briefly, looks like the frame to parent frame pointer got jumbled up. The immediate parent frame of call3 is line local hello = call1(10) instead of return call3(b) in call2 like I'd expect.

[edolphin-ydf]

This is because of the tail call.

If modify the function call3 like this

function call3(c)
    print(debug.traceback())
    return c
end

The output is

stack traceback:
        main.lua:10: in function <main.lua:9>
        (tailcall): ?
        (tailcall): ?
        main.lua:18: in main chunk
        [G]: ?

And i cann't find any api which can check whether the frame is a tail call (the Debug.frame isn't exported).

So have no idea how to fix this.

[Ferix9288]

Ah I see : ( This is not that important at all but I will revisit if I have the time and maybe brainstorm with you. Thanks @edolphin-ydf for looking into this!