Infinite loop in rich_text_label.cpp (ERROR: _process_line: Index line = 0 is out of bounds) #38058
Comments
|
This code is weird. |
|
I haven't looked majorly into this, but I think that the caching system and this check might be what's returning garbage line size values as well. So I think this is possibly related to #18722. @DrMoriarty I haven't had a chance to reproduce this myself and can't find a way to reproduce it. If someone else can try getting a gdb trace on this, that'd be very useful. For the record, as someone who has worked on this class within the last year (or two I suppose), the problem this class currently has is that the codeflow is hard to parse because of a combination of extensive macro-use and arguably too many vaguely named variables. It's kind of on my
@aaronfranke Indeed. I think there's a very high likelihood that these checks were actually intended for the macro define on |
|
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. |
|
Just wanted to confirm that I'm now getting this same error, every single time I push a build to my Android phone for debugging, and it seems to have started as soon as I started using ResourceInteractiveLoader to switch scenes. Removing that part of the code doesn't seem to have stopped this issue from happening every time I run the debugger, but disabling "Small Deploy with Network FS" seems to work. This also seems to only affect Android as far as I can tell, and not when I run a debug build on Windows 10. |
|
I'm working on a C++ module and I'm having the same experience as @HungryProton. I do procedural generation from a thread and this happens sometimes when I use print_line(). The reproduction rate seems arbitrary. |
|
@Eoin-ONeill-Yokai I have a trace from commit 561438c GDB bt#0 0x00007ffff76ef4bf in write () from /lib64/libc.so.6
#1 0x00007ffff767f4cd in _IO_file_write@@GLIBC_2.2.5 () from /lib64/libc.so.6
#2 0x00007ffff767e826 in new_do_write () from /lib64/libc.so.6
#3 0x00007ffff767fbfe in __GI__IO_file_xsputn () from /lib64/libc.so.6
#4 0x00007ffff766b6b1 in buffered_vfprintf () from /lib64/libc.so.6
#5 0x00007ffff7668654 in __vfprintf_internal () from /lib64/libc.so.6
#6 0x0000000006e549cd in StdLogger::logv (this=0x77d6750, p_format=0x1b21d10 "%sERROR:%s %s\n",
p_list=0x7fffffffab70, p_err=true) at core/io/logger.cpp:230
#7 0x0000000006e53901 in Logger::logf_error (this=0x77d6750, p_format=0x1b21d10 "%sERROR:%s %s\n")
at core/io/logger.cpp:100
#8 0x00000000048b0543 in UnixTerminalLogger::log_error (this=0x77d6750,
p_function=0x1b453da "_process_line", p_file=0x1b453e8 "scene/gui/rich_text_label.cpp", p_line=176,
p_code=0x3a4cb630 "Index line = 0 is out of bounds (l.offset_caches.size() = 0).",
p_rationale=0x1b8389b "", p_type=Logger::ERR_ERROR) at drivers/unix/os_unix.cpp:582
#9 0x0000000006e54c59 in CompositeLogger::log_error (this=0x77d6790,
p_function=0x1b453da "_process_line", p_file=0x1b453e8 "scene/gui/rich_text_label.cpp", p_line=176,
p_code=0x3a4cb630 "Index line = 0 is out of bounds (l.offset_caches.size() = 0).",
p_rationale=0x1b8389b "", p_type=Logger::ERR_ERROR) at core/io/logger.cpp:264
#10 0x0000000006cac54a in OS::print_error (this=0x7fffffffd5e8, p_function=0x1b453da "_process_line",
p_file=0x1b453e8 "scene/gui/rich_text_label.cpp", p_line=176,
p_code=0x3a4cb630 "Index line = 0 is out of bounds (l.offset_caches.size() = 0).",
p_rationale=0x1b8389b "", p_type=Logger::ERR_ERROR) at core/os/os.cpp:120
#11 0x0000000006ab6e57 in _err_print_error (p_function=0x1b453da "_process_line",
p_file=0x1b453e8 "scene/gui/rich_text_label.cpp", p_line=176,
p_error=0x3a4cb630 "Index line = 0 is out of bounds (l.offset_caches.size() = 0).",
p_message=0x1b8389b "", p_type=ERR_HANDLER_ERROR) at core/error_macros.cpp:81
#12 0x0000000006ab7513 in _err_print_index_error (p_function=0x1b453da "_process_line",
p_file=0x1b453e8 "scene/gui/rich_text_label.cpp", p_line=176, p_index=0, p_size=0,
p_index_str=0x1a8d3f2 "line", p_size_str=0x1a18d15 "l.offset_caches.size()", p_message=0x1b8389b "",
fatal=false) at core/error_macros.cpp:110
#13 0x0000000005977a06 in RichTextLabel::_process_line (this=0xe7d23d0, p_frame=0xe7d2a90, p_ofs=...,
y=@0x7fffffffc91c: 172, p_width=1333, p_line=470075, p_mode=RichTextLabel::PROCESS_DRAW,
p_base_font=..., p_base_color=..., p_font_color_shadow=..., p_shadow_as_outline=false,
shadow_ofs=..., p_click_pos=..., r_click_item=0x0, r_click_char=0x0, r_outside=0x0,
p_char_count=18487) at scene/gui/rich_text_label.cpp:176
#14 0x00000000059818fe in RichTextLabel::_notification (this=0xe7d23d0, p_what=30)
at scene/gui/rich_text_label.cpp:1039
#15 0x000000000599626b in RichTextLabel::_notificationv (this=0xe7d23d0, p_notification=30,
p_reversed=false) at scene/gui/rich_text_label.h:39
#16 0x0000000006b45a4b in Object::notification (this=0xe7d23d0, p_notification=30, p_reversed=false)
at core/object.cpp:914
#17 0x00000000056d24d8 in CanvasItem::_update_callback (this=0xe7d23d0) at scene/main/canvas_item.cpp:452
#18 0x00000000056e7764 in MethodBind0::call (this=0x8acf450, p_object=0xe7d23d0, p_args=0x0,
p_arg_count=0, r_error=...) at ./core/method_bind.gen.inc:147
#19 0x0000000006b48f6a in Object::call (this=0xe7d23d0, p_method=..., p_args=0x0, p_argcount=0,
r_error=...) at core/object.cpp:904
#20 0x0000000006a86323 in Callable::call (this=0x7fffe9e31020, p_arguments=0x0, p_argcount=0,
r_return_value=..., r_call_error=...) at core/callable.cpp:52
#21 0x0000000006b3d043 in MessageQueue::_call_function (this=0x78d1990, p_callable=...,
p_args=0x7fffe9e31038, p_argcount=0, p_show_error=false) at core/message_queue.cpp:253
#22 0x0000000006b3d392 in MessageQueue::flush (this=0x78d1990) at core/message_queue.cpp:303
#23 0x000000000575cba5 in SceneTree::idle (this=0x911c180, p_time=0.020833334)
at scene/main/scene_tree.cpp:460
#24 0x00000000035535b5 in Main::iteration () at main/main.cpp:2190
#25 0x00000000035168e6 in OS_LinuxBSD::run (this=0x7fffffffd5e8) at platform/linuxbsd/os_linuxbsd.cpp:259
#26 0x0000000003514276 in main (argc=4, argv=0x7fffffffdac8) at platform/linuxbsd/godot_linuxbsd.cpp:56
|
|
I am using threads, and it's causing this issue to me. I don't understand why it works sometimes, shouldn't we always update GUI from the main thread? I am actually wondering how it works sometimes anyway, I don't think we can update the GUI from a thread other than the main, it seems like there's something that handles such situations in Godot? before private Node _console;
private Node Console
{
get
{
if (_console == null)
_console = GetNode("/root/Console");
return _console;
}
}
public void WriteLine(string text)
{
Console.Call("writeLine", text);
}
public void Write(string text)
{
Console.Call("write", text);
}after private Node _console;
private Queue<string> _logLines = new Queue<string>();
private Queue<string> _logs = new Queue<string>();
private Node Console
{
get
{
if (_console == null)
_console = GetNode("/root/Console");
return _console;
}
}
public void WriteLine(string text)
{
_logLines.Enqueue(text);
}
public void Write(string text)
{
_logs.Enqueue(text);
}
public override void _Process(float delta)
{
base._Process(delta);
while(_logs.Count > 0)
Console.Call("write", _logs.Dequeue());
while(_logLines.Count > 0)
Console.Call("writeLine", _logLines.Dequeue());
} |
|
This just started happening to me quite often in 3.2 branch at commit 49b3750. I'm not explicitly using threads in GDScript land -- only the intrinsic threads the engine itself uses, and the threaded LSP server. Here's the backtrace I was able to catch: |
|
@Rubonnek Well, since there's currently a planned refactor (as seen in RichTextLabel issues tracker), I think that this would likely be addressed by that refactor. Out of curiosity, do you happen to have a scene configuration where this is quickly reproducible? |
|
@Eoin-ONeill-Yokai Unfortunately I wasn't able to reproduce the issue consistently. It just happened to me five times in a row in the same project, but suddenly it stopped happening. I spent a couple of hours trying to reproduce it but to no avail. |
|
I can add that it always happened when one of my |
Calinou
changed the title
|
I'm not using threads, for me if you enable verbose debugging and output a bunch into the godot console on re-importing an FBX file which is particularly big and click the scrollbar it will sometimes trigger the problem, but only if the log is super long. maybe someone could make a print_verbose somewhere with like 100,000 lines into the console to debug the issue it might reveal the problem |
|
I was on 3.3.3-RC and just switched to 3.3.3-Stable, and am now seeing this issue. |
|
I was on v3.3.3.stable.official [b973f99], running with -verbose on the editor and testing the game. I was messing with a script, and decided to run a test scene, after I pressed run scene, I noticed that the debug print panel it was still loading some texture resources from my project, the game started on the scene running, everything okay, then suddenly it frooze, upon going to the print there was the error: Looped to infinity until I closed Godot. I had this bug twice in a row, I was going to update to a newer version to test if it still happenned, but it suddenly stopped giving the error. I don't know what triggered, and the thing is, I never had that bug, and I did not executed any major changes aside from running with -verbose, and I also didn't edited anything related to richtextlabels in a loong while, so I cannot pinpoint the error. Also found 2 closed issues with the same problem. |
|
I've ran into this using 3.4 stable. Where the editor will indefinitely freeze up while continuously outputting: 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'm currently on 3.4-stable. I've had the editor periodically crash when I switch back to it after making changes in VSCode. It freezes for about 30 seconds then finally crashes. It's rare, so I don't have any idea how to reproduce it. It's been happening for several weeks. It wasn't until today that I ran the editor from the command line and saw this error message. I couldn't see whether there was anything before it in the logs because it prints it out a LOT. Weirdly, I'm not using
|
|
I'm seeing this on 3.3.4 stable with scripts that run in Removing the print statements prevents the issue, but also makes debugging that code next to impossible without creating a non-threaded sandbox in which to test it. |
If this is reproducible with a stack trace, could you supply a minimum testing environment? It might help with debugging. |
Same here. Doing a terrain sculpting addon. I thought it went away, but it's back now :'(
Seems to be the same here! |
|
Same happening to me. Using v3.4.3 to build an addon with multi-threads and this was popping up a lot. I did something horrible just to be able to use print to debug: func fakeprint(msg):
print(msg)Then inside a method that runs on a different thread I do: func whatever():
call_deferred("fakeprint", ["print me"]) |
|
I am still getting this in 3.5.rc and might be able to provide additional information. This error will not occur if the output console is minimized so that it's no longer visible. I have also been able to get the following stack log that leads to In regards to the |
|
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: Note that decreasing the delay will cause the output text to become increasingly more garbled |
|
I've hit what looks to be this problem in 3.5 on Windows. After having my program lock up pretty consistently (it fails when I hit an "export" button in my project ~90% of the time) and not being able to see the error, I went back to 3.4.4 and saw the symptoms described above in the debug console. |
|
I wonder if using call_deferred instead of call in the MessageQueue would help here. I can't help but wonder if there's some kind of String-based data race happening here where the memory gets garbled before it reaches the rich text. It might be worth a test in the next few days. |
|
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
Unable to reproduce with
System information Steps to reproduce
Video (from Mac, but similar is seen on Linux) Minimal reproduction project Notes
|
|
I'm unable to reproduce this on master when building for x64, but it's pretty consistently cropping up when building and running the x32 version on Windows. |
Just to be clear, do you mean that it's reproducible for a Win32 x86_32 build of the |
@akien-mga I'll give it more testing later, but I seemed to be getting a pretty consistent crash on x86_32 build on my 64bit Windows when using master when trying one of the user's provided test project -- though the importance of this is debatable. I'll provide the backtrace when I give it more testing. I'm not entirely sure this is a RichTextLabel / Godot problem or perhaps just a problem with the users test file as a whole (doing something weird, causing a data race which results in undefined behavior) though so I'll also look through the test project more. |
|
@akien-mga Ah, the error on master is actually caused by improper cleanliness of threads in DataPlusProgram's example project. In their example, the thread should probably be stored as a member of the plugin so that it doesn't go out of scope and get (eventually) cleaned up. So it's worth noting that particular example project might not be an accurate test. |
|
could you clarify what would be the correct way to handle this as I have moved the scope of the thread but I still see the same issues: |
Is this on 4.0 (master branch / alpha) or is this a 3.x specific issue? I think the confusion right now is around which versions have had this issue. Judging by the gdscript example, this still looks like a 3.X related issue. I'll double back and check 3.X to see if I can find a solution that doesn't involve bundling all the changes made in 4.X. As far as I could tell, this issue is now gone in 4.X. And yeah that should be correct now. |
|
Yes it's 3.x and still produces the same errors as a mentioned previously. |
and others
Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.
Godot version:
Godot 3.2.2.beta1
OS/device including version:
MacOSX 10.14.6 (18G95)
Issue description:
Today all day I'm working on fixing pvrtc and twice my godot did hung up with this errors:
It repeats in infinite cycle and godot interface is frozen. I can not reproduce it when I want to. But two times it happened.
Steps to reproduce:
Minimal reproduction project:
The text was updated successfully, but these errors were encountered: