Provide stack trace information for deferred calls

[KoBeWi]

Describe the project you are working on

A very complex game project.

Describe the problem or limitation you are having in your project

When you add a breakpoint in a method and call it, you get a nice stack trace that points to where the method was called.

This is not the case with deferred calls. The only "stack" trace you get is the call itself. But my actual problem are mostly errors. I was just hit with many Node::add_child: Parameter "p_child" is null. errors. The problem is that add_child() often needs to be called in deferred mode. This is also the case in my code - there is no way I can tell which of the tens of deferred add_child() calls is causing this error, because deferred call doesn't give me the necessary call stack info.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

When a method is called in deferred mode, provide the stack trace that points to the original caller, just like with regular calls.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The stack is lost because the deferred calls go through message queue. A possible solution would be adding a debug-only metadata for each call that keeps stack trace information.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No. The "workaround" is to avoid deferred calls, but it's often impossible.

Is there a reason why this should be core and not an add-on in the asset library?

It is core.

[zinnschlag]

A possible solution would be adding a debug-only metadata for each call that keeps stack trace information.

Sounds to me like the only possible solution. And a potentially expensive one, since the stack trace would have to be copied. The original call stack will have been lost by the time the deferred function is executed.

If this enhancement is implemented it should be run through some performance tests (in a heavy duty scenario, e.g. many calls and deep call stacks) and if these warrant it maybe add a project setting to disable the feature. Even if it is only for debugging, performance can't be ignored completely.

But I agree. This would be a very useful feature.

[Calinou]

• Related to Add a project setting to display a full stack trace for errors and warnings #963.

[derammo]

Assuming you only want this to work for scripts, not native code, and you really only want to know where you came from without having the full stack:

Not sure what the threshold is for "a few lines of script" in the workaround question. If you always deferred called some other method on yourself that is properly named based on its purpose, and then called stuff from there, you would get a stack trace that shows which of you many purpose-specific deferred calls was used. If you only called each of those from one place, then you'd know what you wanted to know.

That makes your code very verbose, but it could be done for you by the Script compiler without changing the VM. In other words, rather than tunneling debug data, a debug mode could have the compiler emit a separate function for every deferred call from a class. Then this "wrapper" function could have a stack frame that includes information about where the call location was. That's the best I could do without changing the VM. It's also pretty gross.

And a potentially expensive one, since the stack trace would have to be copied. The original call stack will have been lost by the time the deferred function is executed.

100%