Get current stack trace?

[tottaka]

Hello, I am wondering if there is a current method for retrieving the current stack trace (call stack) in an Engine instance? Or is this something I would have to implement myself using the DebugHandler?

I see there is a ResetCallStack method in the Engine class, but nothing like GetCallStack. Is that something that can be implemented?

[lahma]

For JS side it's just new Error().stack but is it that you want to use it somewhere inside the engine, what's your use case?

[tottaka]

Thank you for the response, my use case is that I have implemented the console.log/warn/ect... functions like in browser JS, and I want to be able to display the call stack from the engine side for certain log levels. So say for instance I call console.warn on the JS side, I want the underlying Console.WriteLine in C# to also output the call stack

[lahma]

I had a quick look and in its current state, it can be hard to get a stack trace. This is because your code (ClrFunctionInstance) is invoked and actual location is bound outside of it (statement running) and only in exceptional cases (when exception is thrown) the final stack trace is created based on the running statement (one that caused your code invocation).

[Jither]

Not sure if I'm missing an implementation issue, but there shouldn't really be a need to implement much yourself if using the DebugHandler - it already gives you access to the call stack for each step - which means you get the current callstack in the Step handler right before the invocation of console.warn (or any other statement). DebugMode does add a bit of overhead, though. This example of a mostly complete debugger (except for pausing a running app) saves the current DebugInformation when the Step handler is called, then uses it to output the call stack on demand:

https://github.com/Jither/Jint.DebuggerExample/blob/ee6dcf4bd25e2a8dd0535b5fa0e7d38636c39bae/Jint.DebuggerExample/Debugger.cs#L153

The (latest) DebugHandler gives constant access to the current location - without even having a Step handler, as long as DebugMode is set - for exactly the purpose of outputting the location in console functions (for the WIP Jint.DebugAdapter). Might want to add constant (lazy) access to CallStack too, for the same use case. Eventually, it might make sense to get rid of DebugInformation entirely, and have it all as properties directly on DebugHandler, removing an allocation and increasing the flexibility in terms of how the information can be retrieved (would also help when implementing console.trace). Might also mean (unless I'm forgetting something, which I probably am) that we could short circuit OnStep in the DebugHandler when no event handlers (Step, Break, the future Skip) are registered, but DebugMode is still enabled. And just store the props required for providing the debug information. Then it may all be used in other engine-side code with minimal overhead (when there's no need to check breakpoints, call stack depth for step in/out, etc.)