Note:
Casting to the C++ classes and calling the methods there would work as well,
but would require including he header files for the specific object types handled
here, which wouldn't be OK either.
This commit addresses multiple issues with `Variant`s that point to an `Object`
which is later released, when it's tried to be accessed again.
Formerly, **while running on the debugger the system would check if the instance id was
still valid** to print warnings or return special values. Some cases weren't being
warned about whatsoever.
Also, a newly allocated `Object` could happen to be allocated at the same memory
address of an old one, making cases of use hard to find and having **`Variant`s pointing
to the old one magically reassigned to the new**.
This commit makes the engine realize all these situations **under debugging**
so you can detect and fix them. Running without a debugger attached will still
behave as it always did.
Also the warning messages have been extended and made clearer.
All that said, in the name of performance there's still one possible case of undefined
behavior: in multithreaded scripts there would be a race condition between a thread freeing
an `Object` and another one trying to operate on it. The latter may not realize the
`Object` has been freed soon enough. But that's a case of bad scripting that was never
supported anyway.
We used a lock signals in the signal_map while emitting, because it was
not allowed to disconnect them while being emitted.
We used that lock to check if we where deleting an object during signal
emission.
Now that we allow to disconnect signals while they are being emitted, if
an object first disconnects, then gets deleted we can't know that a
signal was being emitted during the destructor.
This commit adds a new `_emitting` boolean member to Object to be set
while emitting and checked in the destructor, while removing the old
signal lock which is now unused.
According to https://github.com/godotengine/godot/commit/22637beb2ed625c3e43ab75ab5865b57d7470948#commitcomment-36651823
and as confirmed by @reduz, this seems not to be necessary now that we
copy-on-write.
This triggered freeze scenarios in cases where a node would be deleted
while being used as a target in a signal emission.
Fixes#34650.
Fixes#34769.
Now those two errors go back to reporting:
```
ERROR: emit_signal: Condition ' !target ' is true. Continuing..:
At: core/object.cpp:1191.
```
It will now give information about the originating object instance
and when locked, the target callback.
This should help debugging editor and game issues that are now being
reported due to adding signal locking in
22637beb2e.
Happy new year to the wonderful Godot community!
We're starting a new decade with a well-established, non-profit, free
and open source game engine, and tons of further improvements in the
pipeline from hundreds of contributors.
Godot will keep getting better, and we're looking forward to all the
games that the community will keep developing and releasing with it.
Condensed some if and ERR statements. Added dots to end of error messages
Couldn't figure out EXPLAINC. These files gave me trouble: core/error_macros.h, core/io/file_access_buffered_fa.h (where is it?),
core/os/memory.cpp,
drivers/png/png_driver_common.cpp,
drivers/xaudio2/audio_driver_xaudio2.cpp (where is it?)
Hugo Locurcio
Wilson E. Alvarez
Pedro J. Estébanez
Rémi Verschelde
PouleyKetchoupp
Fabio Alessandrelli
Haoyu Qiu
Juan Linietsky
Bojidar Marinov
qarmin
Braden Bodily