Make get_stack() available in release/debug export templates as well as in the editor

[rslepon]

Describe the project you are working on:
I am developing a story-driven turn-based tactical game.

Describe how this feature / enhancement will help your project:
Bugs happen even in released games. Having an error log with a stack trace would help in debugging.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:
N/A

Describe implementation detail for your proposal (in code), if possible:
Currently get_stack() seems to work only in the editor, as far as I can see. I believe it may be even more useful in the exported exe (in debug and release mode), so I suggest making it work there too.

Here is a function I was planning to use in my game as a replacement for assert():

# replacement for assert, aborting in debug mode, logging in debug and release modes
func ass (cond :  bool, # if conditional is not true, pretty fatal
          msg  := ""    # message to print to log
         ) -> void:
   var fh  := File.new() # file handle
   var err := OK         # error code

   # if failed
   if not cond:

      # open new file
      err = fh.open(D.LOG_FILE_PATH_FULL, File.READ_WRITE)
      assert(err == OK)

      # write to log
      fh.store_line("%d: %s" % [OS.get_ticks_msec(), msg])
      fh.store_line(str(get_stack()))

      # close file
      fh.close()

      # abort in debug mode
      assert(cond)

It works just fine, except that get_stack() returns an empty array in the exported exe (regardless of whether "Export With Debug" is checked or not), where it is most needed, since in the editor the information is already available in the debugger.

P.S. I expect the same could be said for print_stack() too.

P.P.S. I am suggesting to add this as an optional project (or export) setting (off by default). If one wished to pay the performance penalty for the added debug capability (I would), then one would enable that setting.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Not that I can see.

Is there a reason why this should be core and not an add-on in the asset library?:
It's a very basic debug feature that I would expect it to be useful for every game being developed.

[Zylann]

C# is able to retrieve call stacks in release builds (might miss file and line tho) without noticeable performance penalty (apart from the time it actually gets retrieved ofc) so I would not really expect GDScript to be tremendously slowed down. Being able to log errors with call stack is a really useful feature when you can get these logs from players (not just when calling get_stack() explicitely). It might be a security problem in some cases but that's what obfuscation is usually for (not supported tho).

[Galileo53]

We already have built our project with an error reporting system similar to that decribed here to be able to get error reports from the players. Only to find out now that this work was in vain because it does nothing when exported.

I want to give this issue a push because I think it can be extremely useful. As a minimum, if performance is an issue, I can imagine providing at least one function get_line_number() that would return the current line number as shown in the editor, and therefore identify the location of the error (together with a scene name).

[Error7Studios]

I would definitely use this.
I tried to make my own assert() alternative for release builds today, and ran into this problem.
@Calinou , I don't see this mentioned anywhere in the 3.2 changelog.
Is this feature coming?

[Calinou]

@Error7Studios Nobody has started working on it yet, so no, sorry. It'd be helpful for my GDScript Online project too, but I don't know how difficult it would be to implement.

[vnen]

The stack info is not kept in release builds, that's why the function doesn't work (the inherent C++ stack is enough to keep the flow). We never really need to unwind the stack, since GDScript doesn't have exceptions, so keeping the stack is not needed by the engine itself.

I don't see this mentioned anywhere in the 3.2 changelog.
Is this feature coming?

Note that this is the repository for community proposals. A ticket here needs to be considered first by the core team before being added to the roadmap.

[ghost]

Would be nice as a project option to do logging in beta builds. As far as I can tell it doesn't work in debug builds either.

[briansemrau]

Unsure if this works in release builds, but running the project with command line option --debug should enable the debugger. I believe this should allow these functions to work (at least in master. I haven't looked at the implementation in 3.x).

The docs are a bit sparse on this: https://docs.godotengine.org/en/stable/getting_started/editor/command_line_tutorial.html#debugging

[Calinou]

Unsure if this works in release builds, but running the project with command line option --debug should enable the debugger. I believe this should allow these functions to work (at least in master. I haven't looked at the implementation in 3.x).

This should work in debug export templates, but it won't work in release export templates.

If you want to use a debug export template without a console window appearing on Windows, compile a debug export template with the tools=no target=release_debug windows_subsystem=gui SCons options.

[dalexeev]

• This can probably be resolved by Ability to print and log script backtraces godot#91006.