godot: Infinite loop in rich_text_label.cpp (ERROR: _process_line: Index line = 0 is out of bounds)

Not sure if it’s related but this issue consistently happens since I tried adding multi-threading to my addon. I’ll see if I can produce a minimal reproduction project but the code is so convoluted I’m having a hard time tracking down this issue.

I’ve ran into this using 3.4 stable. Where the editor will indefinitely freeze up while continuously outputting: Index line = 0 is out of bounds (l.offset_caches.size() = 0).

It happens with my plugin when threading and printing is involved.

Removing the print statements stopped the editor from outputting this error and freezing.

I have created a minimal reproduction project for this issue.

In order to see the issue enable the plugin and make sure that the Godot editor output console is visible. After a few seconds it will start producing the error.

Note that if the editors output is not visible the error won’t occur but the editor will soon freeze once it’s visible.

The error is produced by calling this function within a thread created by the plugin:

func printOut():
	while(true):
		print("print out ------------------------------------")
		OS.delay_msec(1)

Note that decreasing the delay will cause the output text to become increasingly more garbled

richTextError.zip

I am running into the same issue.

My minimal reproduction project does not contain any scenes, scripts, exporting, or anything with threads. It is three nearly empty resource files and a project.godot

Godot version

Tested on both Mac and Linux

Reproduced with

• 3.4.4-stable
• 3.5-stable
• 3.5-stable custom build (tag: 3.5-stable) Mac: scons platform=osx arch=arm64 target=release_debug Linux: scons platform=x11 arch=x64 target=release_debug
• 3.5.1-rc1

Unable to reproduce with

• 3.5-stable custom build (tag: 3.5-stable) Mac: scons platform=osx arch=arm64 target=debug Linux: scons platform=x11 arch=x64 target=debug
• 4.0rc14

System information Mac M1 Ubuntu 20.04.1

Steps to reproduce

1. Extract the zip file somewhere, and cd into it

2. Clear the cache and launch the editor from the command line

   • Mac

       rm -rf ~/Library/Caches/Godot
       /path/to/Godot -v --path . --editor
     

   • Linux

       rm -rf ~/.cache/godot
       /path/to/Godot_v3.5-stable_x11.64 -v --path . --editor
     

3. In the editor, click on Output to view the output. You should see something similar to this.

    Godot Engine v3.5.stable.official (c) 2007-2022 Juan Linietsky, Ariel Manzur & Godot Contributors.
    Loaded builtin certs
    --- GDScript language server started ---
    EditorSettings: Save OK!
    Loading resource: res://dynamicfont.tres
    Loading resource: res://dynamicfontdata1.tres 
    Loading resource: res://dynamicfontdata2.tres
    Loading resource: res://dynamicfontdata1.tres
    Loading resource: res://dynamicfontdata2.tres
   

   • The Output window must remain open to reproduce the bug, so leave it open.

4. Right click on dynamicfont.tres, then choose “Duplicate” and give it a different name.

   • You may have to do this several times (usually less than ten times, if it’ll repro). On Mac I’ve had the best success; where duplicating dynamicfont.tres just once reproduces the problem. On Linux I’ve had less luck, where I’d have to duplicate dynamicfont.tres (or any of the duplicates) 5 to 10 times (and even quit the editor, clear the cache, and restart the editor) before the bug occurs.

5. Watch the editor freeze.

6. This error message is spammed in the terminal

    ERROR: Index line = 0 is out of bounds (l.offset_caches.size() = 0).
       at: _process_line (scene/gui/rich_text_label.cpp:168)
   

Video (from Mac, but similar is seen on Linux) https://user-images.githubusercontent.com/109488824/189353599-4b3b4373-d20c-471e-9cc7-1c54aeadcdbe.mp4

Minimal reproduction project DynamicFontInfiniteLoop.zip

Notes

• As mentioned earlier, the Output window must be opened to reproduce the bug. I suspect that Output is implemented with a rich_text_label.

• When you duplicate a resource, and the bug does not occur, you must see something like this in the Output

    Duplicating res://dynamicfont.tres -> res://a.tres
    FileSystem: calling rescan.
    Loading resource: res://a.tres
    Loading resource: res://dynamicfontdata1.tres
    Loading resource: res://dynamicfontdata2.tres
  

  If you only see

    Duplicating res://dynamicfont.tres -> res://a.tres
    FileSystem: calling rescan.
  

  Then the bug has no chance of happening. To see the bug, Godot must “reload” the resource when you duplicate it. To make this happen, exit the editor, clear the cache, and restart the editor Alternatively, name the duplicate resource something unique (in my case, b.tres hasn’t been used in any editor session yet)

• The reproduction steps clear the Godot cache. This is to ensure duplicated resources are “reloaded”, even if Godot has loaded that file in a previous editor session. For example, if a previous editing session loaded a.tres, then Godot will not reload it unless if the cache was cleared before launching the editor.

• -v (--verbose) makes it reproducible 100% of the time. In this minimal project, I wasn’t successful in reproducing the failure without -v. In my actual project, the failure seemed random when -v was omitted since it only happened when Godot would also load the duplicate resource. It is obvious when Godot loads the duplicate resource because I had code that printed text when _init() was called.

• The DynamicFont resource (dynamicfont.tres) must load two or more ExtResources. I couldn’t reproduce the problem with SubResources nor with only one ExtResource.

• This minimal project points to two ttf fonts that do not exist. The problem occurs regardless if they point to real ttfs or not.