Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some C# Signals Don't Automatically Disconnect After QueueFree #89116

Closed
atlasapplications opened this issue Mar 3, 2024 · 5 comments
Closed
Labels

Comments

@atlasapplications
Copy link

Tested versions

Reproducible in v4.2.1.stable.mono.official [b09f793]

System information

Windows 11

Issue description

Certain kinds of signals connected with C# does not automatically disconnect after the Node is freed. Intended functionality should be that all connected signals should be automatically disconnected as part of the cleanup process. An example of a signal that doesn't disconnect is you have Node A that defines a user created signal. Node B connects that signals on _Ready(). When Node B is removed with QueueFree() and Node A emits the signal, Node B, which has been deleted from memory, still executes the connected signal. A workaround is on _ExitTree() you can manually disconnect the signal but this should not be necessary.

Steps to reproduce

  1. Create a signal in a Node.
  2. Connect the signal in a second Node.
  3. Free that second Node.
  4. Emit the signal in the original Node.
  5. Verify with IsInstanceValid()

Minimal reproduction project (MRP)

c_sharp_signal_bug.zip

@atlasapplications
Copy link
Author

As a note that may be helpful, using the older way of connecting signals Connect(), which was the only way to connect signals in Godot 3 does work as intended still. This only applies to the newer way of connecting signals in Godot 4 with C# which is with the event handler += operator.

@markdibarry
Copy link
Contributor

This is a known issue.. So much so, it's in the documentation.

@atlasapplications
Copy link
Author

This is a known issue.. So much so, it's in the documentation.

I was unaware it was a known issue, so thank you for pointing that out! I will note that the documentation you referred to is not for the stable version of the engine so the reach of that info may be a bit harder to come by until 4.3 comes around. Should I close the issue since it's a duplicate?

@AThousandShips
Copy link
Member

It just hasn't been cherry picked yet, it will be as it's marked for cherry picking, so this can be closed :)

@atlasapplications
Copy link
Author

It just hasn't been cherry picked yet, it will be as it's marked for cherry picking, so this can be closed :)

Sounds good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants