"Bad address index" error is printed when there is a cyclic reference in a script

[nobe4]

Godot version

v4.0.stable.official [92bee43]

System information

macOS 13.2.1 (22D68), Intel Intel(R) Iris(TM) Plus Graphics - Supported, Integrated Vulkan API 1.2.231 - Forward+

Issue description

Howdy 👋

I came across a weird error that I've narrowed down to:

• Inherited scenes
• Inherited class
• Instantiation

When using a combination of those, I get:

Steps to reproduce

This is a very reduced version of a project I work on, so don't expect it to "make sense".

Since the code is so short, here's:

# base.gd
extends Node2D
func _ready(): add_child(preload("res://blue.tscn").instantiate())

# red.gd
extends Node
class_name Red
var something = 1

# blue.gd
extends Red
class_name Blue
func _ready(): get_parent().add_child(preload("res://green.tscn").instantiate())

# green.gd
extends Blue

In the same fashion, blue.tscn is inherited from red.tscn and green.tscn is inherited from blue.tscn.

When this code runs, it fails on var something = 1 with the error:

Maybe related to this?

godot/modules/gdscript/gdscript_vm.cpp

Line 633 in 31eccb5

err_text = "Bad address index."; \

There are a few changes that prevent the code from failing:

• remove/comment var something = 1
• make Red and/or Blue and/or Green extends from ColorRect
• remove green.gd script from the green.tscn scene

Minimal reproduction project

Archive.zip

[Rindbee]

There is a cycle between Blue and Green. The inheritance relationship in scenes is opposite to that in scripts.

Using load instead of preload should work, but gets stuck in an infinite recursion in _ready. Errors occur either at parse time or at runtime.

[nobe4]

Ah good catch, is this a case where a cycle should be detected and give a more meaningful message?

[tavurth]

Would be great to have some more direction when attempting to fix such errors.

Even the filenames which are cyclic would be a great improvement. Actually I'm fine without circular dependance, but there's very little tooling at the moment to help with debugging this.

Currently refactoring a bit of my large project, now I'm dealing with this issue again and there's really not much to do except comment out parts of a large section of my codebase until I find the single line which is causing the issue.

Previously it was caused by referencing a class_name inside a function definition, but this time who knows 🤷

[tavurth]

I went and wrote the following gist:
https://gist.github.com/tavurth/0d4c49a0a800cbc27f80c3a68f0c8ee7

Code is a bit messy as I was in a rush, but it works to detect such circular dependencies and can also output a graph of your project.

The class structure of my game:

The circular dependencies detected:

[dalexeev]

4.1 dev:

  scene/resources/resource_format_text.cpp:481 - res://green.tscn:6 - Parse Error: 
  Failed loading resource: res://green.tscn. Make sure resources have been imported by opening the project in the editor at least once.
  scene/resources/packed_scene.cpp:90 - Condition "nc == 0" is true. Returning: nullptr

[tavurth]

@dalexeev this is a different issue I'm pretty sure.

referenced non existent resource

Most likely means that your scene is missing, or corrupted in some other way?

[dalexeev]

I think the ResourceLoader now recognizes this cyclic dependency which is causing the scene to fail to load.

If you replace preload with load, the scene can be opened (after restarting the editor).

• See also preload cause ' cyclic resource inclusion' error #77436.

CC @adamscott

[tavurth]

@dalexeev seems like you are running an example scene anyway? Perhaps you could post the zip here?

[adamscott]

Currently, it's not possible to load cyclically scenes, ie. scenes with scripts that their definitions depend on the loading script.

Originally, I had intended to support this, but my PR couldn't be merged. See the discussion for more info.
#71004

[lamdevhs]

Just in case it helps someone else:

I came across something that seems very similar to this bug. I had the same 'bad address index' error message.

Mine was related to type annotations: I couldn't have var b: B = null in class A, seemingly because in class B at some point I had var a2 = A2.new() with A2 a subclass of A, but Godot was fine with var b = null, though, no error at all.

It was also related to load()ing scenes (of type A, or rather inheriting from A) in an autoload Foo, and my main scene was inheriting from B.

I fixed it in the autoload Foo, simply by transforming
var packed_scene = load("res://inherits_from_A.tscn")
into
@onready var packed_scene = load("res://inherits_from_A.tscn")

Seemingly, without the @onready, Godot tried to load the scene somewhat too early to handle the type reference of B in A (at least that's what I can only assume). Hope it helps!