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

XR throws exception when adding anchor #1383

Open
CedricGuillemet opened this issue May 28, 2024 · 1 comment · May be fixed by #1386
Open

XR throws exception when adding anchor #1383

CedricGuillemet opened this issue May 28, 2024 · 1 comment · May be fixed by #1386
Assignees
Milestone

Comments

@CedricGuillemet
Copy link
Contributor

CedricGuillemet commented May 28, 2024

forum thread https://forum.babylonjs.com/t/babylonreactnative-throws-exception-when-adding-anchor/50716/13

addAnchorPointUsingHitTestResultAsync kicks an exception.

call stack with a bunch of printf:
image
Frame is destroyed before being used for adding an anchor.

This is not an issue until the allocator returns the same allocated pointer. When the pointer is different (an allocation occured in the meantime), then the pointer is invalid. memory is cleared to zero after deallocation.

Investigations:

  • drawFrame happens in dtor for frame. Keeping a smartpointer will make rendering stutter for a few frames.
  • is it possible to attach System::Session::Frame to an object and not destroy/create every frame?
  • This is 1 instance of the unsafe pointer : there and other pointers for XRPlane as well.
@CedricGuillemet CedricGuillemet self-assigned this May 28, 2024
@thomlucc thomlucc added this to the 8.0 milestone May 29, 2024
@CedricGuillemet CedricGuillemet linked a pull request May 31, 2024 that will close this issue
@CedricGuillemet
Copy link
Contributor Author

I've spent more hours today and keep same memory allocation for session::frame doesn't help.
Next try: keep a smart pointer on the session frame. As rendering code is in its destructor, there will be added latency and frozen frames. I think it's possible to fix that with a more explicit method call instead of rendering code in the destructor.

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

Successfully merging a pull request may close this issue.

2 participants