14-02-2022, 09:03 AM
(This post was last modified: 14-02-2022, 09:06 AM by josemendez.)
Hi there!
GetPointCloudAnisotropy() is only called when there's fluid particles present in a solver. I assume you're only using ObiRope, so this method is never actually called. The fact that it appears in the stack trace is a very strong indicator that this issue stems from memory corruption: use of uninitialized memory, out of bounds access on unmanaged memory buffers, etc.
You mention this happens in both backends as well, which makes sense since both backends have identical memory access patterns.
Bad news is that despite the diagnosis being straightforward, these are extremely hard to debug since they can be caused by *literally anything* in your project, including code that's completely unrelated to Obi. The stack trace points you to where the program crashed, but there's no indication to where memory is being incorrectly handled.
The only ways to debug this are either using a memory debugger (Valgrind), and/or slowly dissect the project in a binary-search fashion until the issue disappears, then begin re-adding stuff until the issue is narrowed down.
Ropes themselves do not perform any kind of memory handling at runtime: once instantiated, they do not allocate anything nor are they moved around in memory. It's safe to assume that ropes are not the culprit. You do mention that there's many rigidbodies/colliders being enabled/disabled at runtime, and that the issue happened in-editor while working on procedural generation of these: that's a good starting point.
Could you share more details about the pattern in which these are enabled/disabled? Ideally, share the script(s) you use to procedurally generate these?
kind regards,
Quote:0x00007FFC8E5EB319 (libOni) GetPointCloudAnisotropy
GetPointCloudAnisotropy() is only called when there's fluid particles present in a solver. I assume you're only using ObiRope, so this method is never actually called. The fact that it appears in the stack trace is a very strong indicator that this issue stems from memory corruption: use of uninitialized memory, out of bounds access on unmanaged memory buffers, etc.
You mention this happens in both backends as well, which makes sense since both backends have identical memory access patterns.
Bad news is that despite the diagnosis being straightforward, these are extremely hard to debug since they can be caused by *literally anything* in your project, including code that's completely unrelated to Obi. The stack trace points you to where the program crashed, but there's no indication to where memory is being incorrectly handled.
The only ways to debug this are either using a memory debugger (Valgrind), and/or slowly dissect the project in a binary-search fashion until the issue disappears, then begin re-adding stuff until the issue is narrowed down.
Ropes themselves do not perform any kind of memory handling at runtime: once instantiated, they do not allocate anything nor are they moved around in memory. It's safe to assume that ropes are not the culprit. You do mention that there's many rigidbodies/colliders being enabled/disabled at runtime, and that the issue happened in-editor while working on procedural generation of these: that's a good starting point.
Could you share more details about the pattern in which these are enabled/disabled? Ideally, share the script(s) you use to procedurally generate these?
kind regards,