godotengine / godotengine/godot

Node Instantiation Fails with NativeAOT Enabled in Export Release Mode

Open
#96,072 7 comments 1 reaction 0 assignees View on GitHub
needs testing platform:ios topic:dotnet topic:export
Dominant language
C++
Stars
117k
Forks
26.8k
PR merge metrics
PR metrics pending

Description

### Tested versions

- Reproducible in Godot v4.3.stable.mono
- Reproducible in Godot v4.2.x.stable.mono (although the error text is different)

### System information

iOS 17.6.1 (Not in debug mode)
Windows 11 (NativeAOT enabled & release mode)

### Issue description

~~This is a bug that appears to only affect iOS based devices when distributing one's `.ipa` through Apple's App Store (so App Store Connect). This does not occur on iOS when distributing through a debug build on Xcode. When I first load my scene, many of the `Nodes` load properly, but when I get to the top level `Node3D` that contains most of my game level, it fails to instantiate. The error logs show this:~~
```
USER ERROR: Index nprops[j].value = 61545 is out of bounds (prop_count = 58).
at: instantiate (scene/resources/packed_scene.cpp:314)
```
~~This leads me to believe that it could be related to Apple's restrictions on dynamic code via reflection which is still present in some of Godot's codebase for C#. I tested this with a release build on Android through Google Play and this error does not occur there either.~~

**UPDATE**
It took a long time for me to figure out the exact configuration that was causing the primary world `Node3D` from instancing since my project has over a hundred `Node3D` instances that are a part of that `PackedScene`. However, I believe I've narrowed it down to a single `MeshInstance3D` that appears to be responsible.

This `MeshInstance3D` has a script attached that utilizes an `[Export]` variable of type `StandardMaterial3D` and applies that to the `MeshInstance3D` on `_Ready()`. I apply a default value in the editor. And in the actual root world where I drag and drop multiple instances I replace this `[Export]` value with various different `StandardMaterial3D` assets. When I remove the `[Export]` variable and just supply the `StandardMaterial3D` with `ResourceLoader.Load()` instead, the error no longer occurs.

Sooo, the workaround is to **NOT** use `[Export]` for `Object`s that inherit from `[Resource]`. As a side note, I also back all of my `Resource`s that I instance from `ResourceLoader` into a static `Dictionary` that prevents premature disposal of `Resource`s. This may or may not be a separate issue altogether which I note below, but seems related.

This is a **difficult** bug to reproduce as I've not found a way yet to create a minimal reproduction sample. My guess is that this bug only has a small chance of happening but since my project has so many eligible `Nodes` for this bug to occur, it was happening to me almost all the time. Nonetheless, here's how one may encounter it...

### Steps to reproduce

- Create a project with a basic world that has `Node3D` as the root.
- Create another `Node3D` with a `MeshInstance3D` and attach a script.
- That script should contain an `[Export]` variable that is some kind of material like `StandardMaterial3D`.
- Give that material a default value in the editor. (not in the script)
- Apply that material to the `MeshInstance3D` on `_Ready()`
- Now put multiple instances of these `MeshInstance3D` nodes in the world.
- Give each of those instances a different value for the [Export] variable in the root world.
- Export with NativeAOT enabled and debug mode off. (Can also be iOS uploaded to App Store Connect since those are the defaults)

### Minimal reproduction project (MRP)

N/A

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.