[go: nahoru, domu]

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

Crash when using get_gravity from _process while running physics on separate thread #87975

Closed
mihe opened this issue Feb 5, 2024 · 5 comments · Fixed by #87976
Closed

Crash when using get_gravity from _process while running physics on separate thread #87975

mihe opened this issue Feb 5, 2024 · 5 comments · Fixed by #87976

Comments

@mihe
Copy link
Contributor
mihe commented Feb 5, 2024

Tested versions

Reproducible in: 4.3-dev [acde2a8]

System information

Windows 11 (10.0.22631)

Issue description

The new get_gravity method that was added in #84640 relies on body_get_direct_state, which is not accessible outside of _physics_process and _integrate_forces when using the physics/*d/run_on_separate_thread project setting.

As such, it ends up throwing an error here:

ERR_FAIL_COND_V_MSG((using_threads && !doing_sync), nullptr, "Body state is inaccessible right now, wait for iteration or physics process notification.");

... and subsequently crashes due to a nullptr access in get_gravity.

Steps to reproduce

  • Run the MRP
  • Observe crash

Minimal reproduction project (MRP)

GravityCrash.zip

@AThousandShips
Copy link
Member

I'm on it

@mihe
Copy link
Contributor Author
mihe commented Feb 5, 2024

I appreciate that an error is preferable to a crash, but this maybe wasn't the fix I had hoped for. :)

I'll make a new issue for the error I guess.

@AThousandShips
Copy link
Member
AThousandShips commented Feb 5, 2024

This matches the rest of the code, wasn't going to add an additional error originally

But you can't avoid an error entirely, what is the issue you're facing with the error? What is your alternative?

A more elaborate fix wouldn't be appropriate I'd say as it's a crash that must be avoided, improvements on it would be separate, but unless you suggest adding a more elaborate caching etc., there should always be an error here when accessed incorrectly

@mihe
Copy link
Contributor Author
mihe commented Feb 5, 2024

Fair enough. Maybe creating an issue wasn't the right tool to use here. Ideally I wouldn't have fumbled the review of #84640 and this could've been discussed prior to merging this change, but alas.

I agree that your fix was the pragmatic fix in this case, and lines up with how get_contact_count does it, and an error is absolutely better than no error. My issue was more with the usage of body_get_direct_state to begin with, but I guess that's a broader topic that's maybe better suited for elsewhere, as you point out.

(Also, I didn't mean for my previous comment to come off as snarky as it did. I appreciate the quick fix, of course.)

@AThousandShips
Copy link
Member

Thank you! Making a report was the appropriate thing to make sure the crash was resolved, that shouldn't have been left untended to, but a broader improvement would be good to discuss too :)

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

Successfully merging a pull request may close this issue.

3 participants