Error in script_editor_debugger.cpp masking debugger output

Help
,
1

Godot Version

v3.6.stable.official [de2f0f147]

Question

I’ve got a project that frequently throws an error with the debugger whenever an error is encountered. The error shown is

editor/script_editor_debugger.cpp:1496 - Condition “cmd.get_type() != Variant::STRING” is true.

This happens (almost) every time any error is encountered. As a test, I currently have assert(false, "debug test") in the code that loads my game. I just launched my game 4 times in a row. The first 3 times, I got the above error, with no more output from the debugger. The last time, I got the expected Assertion failed: debug test with a stack trace. This is making debugging very hard, as the majority of the time when I encounter a problem, I have no error message, stack frames, line number, or any other relevant details.

Since this doesn’t seem to be happening to everyone else (this is a stable build and I assume an issue like this would be caught pretty immediately), there is likely something on my local machine causing this. Could I get some help on where to start looking? I don’t know what cmd.get_type() is doing, or what type it’s returning (just that it’s not Variant::STRING). I’m currently digging through script_editor_debugger.cpp, but this is gonna take me a while to trace by myself.

2

The context around the code is pulling from a packet peer. It seems to be looking for a string and int in this order.

I don’t understand the purpose of file for the error. But your focus on getting type is not the issue.

Also I’m not sure how assert(false) could ever assert with a constant value.

3

Could you explain a bit more about the packet peer? From what I understand (which is limited here), packet peers are used in networking, so I don’t really understand what it’s attempting to do within the debugger.

Also I’m not sure how assert(false) could ever assert with a constant value.

Of course, the intent was to crash. Let me restate the problem: when I encounter any error in my code at all that triggers the debugger, most of the time the debugger immediately crashes with the script_editor_debugger error. This is true for any error in my code, including assert(false), as well as other errors that I come across as a normal part of testing. This makes debugging actual errors very difficult, since when the debugger crashes this way, I can’t tell where the issue in my actual code was, or what the error was, or anything else useful.

(Interestingly, I am not able to reproduce this in a brand new Godot project on the same machine, so I guess something in my project is causing the debugger to crash any time it’s loaded, though I can’t really imagine what.)

4

After doing a bit of digging I realize now that the debugger communicates with the running game process via TCP, which explains the usage of packet peers. So now I guess I’m back to the root question: why is this assertion failing within the debugger? What is it trying to account for, and how could my game possibly be sending such a broken packet for even the simplest errors that it crashes the debugger entirely?

5

I wouldn’t say it’s a broken packet, just that the packet isn’t a string.

When pending_in_queue is zero, it waits till it has two or more, and tries to parse a string and int, in this order, to reset pending_in_queue. For whatever reason the packet isn’t a string.

This string is message_type = cmd;

Int is pending_in_queue = cmd;

Which is later used to parse a message that is a few variants long.

_parse_message(message_type, message);

My only guess is that the client isn’t sending the data in the correct order or someone else is sending packets on the same port that is getting the count off.

I’m just reading the code, and I don’t really know the larger picture.

I would say this code is fragile. But it does kind of sound like your are doing something unconventional.

6

Yeah, that makes sense. My game has 0 networking code, so nothing that’s intentionally sending packets or otherwise causing some sort of conflict. It’s a relatively simple game in terms of what it’s aiming to do (a small 2D single-player game), but clearly I’ve got something configured somewhere that’s doing something odd. It’s a shame the debugger error message doesn’t say any more about the packet it received.

I’ll keep trying things out to see if I can narrow down the scope of the problem at all.

7

Finally figured out what was causing it. I can at least reproduce it in other projects (and work around it in my project) now.

For future reference, it has something to do with overriding _get inside an AutoLoad class, and attempting to call .get from within that function. For a minimal example, I created a new project with one scene, and attached a script to that scene that just asserts false inside _ready. Then I added a second script that just looks like this

extends Node

func _get(property):
    return .get(property)

And set it as an AutoLoad global variable in my project. Running the scene crashes the debugger. Removing the AutoLoad, or commenting out the _get function, or just replacing the return with a return null will all result in a properly running debugger with the failed assertion, stack frames, etc.

I was trying to do some dynamic properties on a global class based on files present in a directory when the class loaded, which actually did work properly while the game was running, but caused issues with the debugger itself. Weird, but OK. I will find another way.

8

Last update just in case this helps someone in the future: just return null from within _get to fallback to the default property lookup. No need to try to explicitly call the parent. From the docs:

Virtual method which can be overridden to customize the return value of get.

Returns the given property. Returns null if the property does not exist.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.