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

Stack Underflow (Engine Bug) on yields. #35705

Closed
acedogblast opened this issue Jan 29, 2020 · 3 comments
Closed

Stack Underflow (Engine Bug) on yields. #35705

acedogblast opened this issue Jan 29, 2020 · 3 comments

Comments

@acedogblast
Copy link

acedogblast commented Jan 29, 2020

Godot version: v3.2.stable.official (Works on v3.1.2.stable)

OS/device including version: Linux/GNU Kubtunu 19.04

Issue description: This bug occurs after a large complex sequence of yields and signals in my group's project. It may be related to issues #30269 and #31455 since the error message in the editor is "Stack Underflow (Engine Bug)".

The only error in the errors tab is:
E 0:00:34.283 _disconnect: Disconnecting nonexistent signal 'loop_end', slot: 2474:_signal_callback.
<C++ Error> Condition "!s->slot_map.has(target)" is true.
<C++ Source> core/object.cpp:1522 @ _disconnect()
BattleBars.gd:83 @ slide_player_exp_bar()

The confusing thing is that the signal 'loop_end' is not part of BattleBars.gd and we are not disconnecting any signals in our code. Again, this bug is not present in version 3.1.2.

Minimal reproduction project: We have not been able to recreate this bug in a minimal project yet.

@acedogblast
Copy link
Author

acedogblast commented Jan 30, 2020

Using call_deferred("method") before yield fixes our problem. Closing.

@avnerh1
Copy link

avnerh1 commented May 13, 2021

Using call_deferred("method") before yield fixes our problem. Closing.

I have the same problem. I couldn't understand what the solution is. Can you provide a short code example with the solution you suggested?

@acedogblast
Copy link
Author

call_deferred(string) is a Godot Object function that calls a specified function during the idle time of the node. It fixed our problem because the function I needed to call is part of a separate node than the one the code is in. The reason why it fixed our problem is that sometimes the node we are trying to call already finished its task and can not be updated in the current frame so call_deferred will make it so that that node on the next frame will then run that specified function.

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

No branches or pull requests

4 participants