-
-
Notifications
You must be signed in to change notification settings - Fork 217
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
Fix more UB in pointer calls, and leaks in general #275
Conversation
API docs are being generated and will be shortly available at: https://godot-rust.github.io/docs/gdext/pr-275 |
bors try |
tryBuild succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
485589c
to
e30d82c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update!
There are now quite a few more types for the GDScript tests: GDScriptExecutableTestCase
, GDScriptHardcodedTestCase
, GDScriptTestCase
(the abstract base), TestSuiteSpecial
. I assume this is all due to the "skipping a physics frame", or any other reason?
Is it possible to inherit TestSuiteSpecial
from TestSuite
for the sake of code reuse?
itest/godot/SpecialTests.gd
Outdated
# Ensure we run a full physics frame | ||
await root.get_tree().physics_frame | ||
await root.get_tree().physics_frame |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This runs two frames, no? If that's truly needed, could you add an explanation to that? At the moment the comments ("one full physics frame") seem to contradict the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from my understanding, it is like this:
the first physics frame signal is emitted at the first physics frame, but at this point no physics has happened yet. the second physics frame signal is emitted at the second physics frame, at this point a full physics frame has been run.
i may be wrong though, but it didn't seem to consistently work with only one at least.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i made the test runner wait for a physics frame instead of a process frame for initialization. that way i only need to wait for one physics frame here
Yeah, it should also be usable if we have another test that we just cant run with our standard itest api.
I'll try, probably, but i think i'd end up rewriting everything in |
Don't worry too much about that refactoring, can always be cleaned up later 🙂 |
e30d82c
to
3b0bff9
Compare
turned out to be pretty simple |
bors try |
tryBuild failed: |
@lilizoey it looks like this no longer passes memory checks with Godot upstream changes and/or #284 🤔 See failed CI job. Undefined behavior
|
Fix incorrect incrementing of refcount when calling in to godot Fix refcount not being incremented when we receive a refcounted object in virtual methods
3b0bff9
to
5b03781
Compare
bors try |
tryBuild succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
bors r+ |
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
Fixes 3 issues, all done together because the test for the first one doesn't pass on latest godot without the other two fixes.
UB in virtual method calls
Fixes UB caused by us dereferencing a pointer incorrectly. We initially assumed that in pointer calls, if an argument is an object then the pointer passed is either a
Ref<T>*
or aT*
, but as it turns out it sometimes isT**
instead. This happens whenever we're making a virtual call (which are always pointer calls) andT
does not inherit fromRefCounted
.Thus when we tried to dereference the pointer we'd be transmuting a
T*
into aT
. Which is UB.closes #267
Improper handling of refcount in virtual methods
We were previously not incrementing the refcount for objects we received in virtual methods. This is incorrect, it is our responsibility to increment the refcount. This seemed correct at the time because of the bug below.
Unnecessary increment of recount on passing values to Godot
When passing a refcounted object to godot we would increment the refcount before passing it along. But godot would assume we did not do this, thus leading to a leak as godot would not decrement the refcount for us.
This made it appear like godot incremented the refcount for us in the tests we had. However it was actually just that we had incremented the refcount and godot did not decrement it.
closes #257