Memory corruption? #86
Assignees
Labels
Comments
|
Hello. Thanks for reporting this. Do you have an entire stack trace of the assert by any chance ? |
|
Hi, I seem to have random crashes. But all happen in RP3D. One stack trace looks like: Not yet sure whats the origin :/ Maybe I will have a session and debug my stuff as well like adding asserts to array access of vector and such. Hmm. Really sure that it is no multithreading issue (I have several worlds in one application as we include server now in game application process and have a additional pathfinding world for both) If I get another crashes I will notify you. I am using a older RP3D 0.7 version. Do you think it makes sense to update? Sometimes RP3D uses several seconds to compute a dynamics world. I guess this is also a misbehaviour due to memory corruption, but I have no prove yet. Just like I said it could happen that the error is on my side. Many thanx and Best regards |
|
Hi, Please see attached a second one: |
|
Thanks. |
|
Hi, I did a quick test and several assertions crashes occurred. I will report exactly soon. Many thanx and |
|
Is there a way for me to checkout your code in order to reproduce on my side ? |
|
The game itself is closed source. I have to decide with our team. I will write you an email. |
|
Ok I understand. I will first try to find the issue without the sources. I am currently busy with another issue and then I will focus on this one. |
|
Hello, You gave me a stack trace for the two following errors:
and
Do you have the states of all the variables of the Set object at the line of the asserts for each of those two errors ? Something seems to be wrong in the Set class and I am trying to figure out what is it. |
|
I will check this and give you infos tomorrow at latest. Most crashes I seem to have are really RP3D set related! |
|
We have implemented game shutdown and such. From time to time I see this assertion:
Backtrace: Variables: Hope this helps for this assertion. |
|
Damn. Tried to catch the other ones. When I get them the backtraces makes no sense and are broken. |
|
E.g. see this backtrace: Every frame < 11 is broken. But this might give a hint still. |
|
Also frame 15 til frame 25 seem to make no sense. |
|
Hi Daniel, I had errors my code regarding multi threading. Now we have only hit the following one after lots of fixes: And sometimes a World::update() takes like 2 seconds. Any idea what this could be about? Many thanx and Best regards |
|
Hello Andreas,
Thanks for your feedback. It very good news that you were able to fix the multithreading issues.
I will investigate the broad-phase error in the updateProxyCollisionShape() function that you reported. Does this happen only from time to time ? Are you able to create physics test where this error occurs (event from time to time) so that it's easier for me to debug it ? Do you have a backtrace of this error with the values of the variables ?
In your backtrace, you have the following two lines:
frame #6: 0x000000000063e16b ASW`reactphysics3d::RigidBody::updateBroadPhaseState(this=0x000000081b4d77c0) const at RigidBody.cpp:560
frame #7: 0x00000000004dac76 ASW`tdme::engine::physics::Body::fromTransformations(this=0x0000000805084180, transformations=<unavailable>) at Body.cpp:505
We can see that the RigidBody::updateBroadPhaseState()method in RigidBody.cpp is called directly from your code in Body.cpp (line 505). How is this possible because the RigidBody::updateBroadPhaseState() method is private in reactphysics3d ? Do you understand this backtrace ?
About the update() taking 2 seconds, I can only see a scenario where there are a lot of collisions to solve in one frame. Maybe you have a lock somewhere that can cause this ?
|
|
Hi, could be that I changed the code for testing, but we had those crashes after that too. I will investigate on next crash and give frame variables and such. Unfortunately it happens rarely. Many thanx and Best regards |
|
Is it possible that the body in which you manually call updateBroadPhaseState() is not part of the physics world anymore ? |
|
Good question. Looked at the code. Rather looks like it can be disabled but not removed. Using: Do you think this could be an issue? |
|
Yes that might be the issue. If you do not want to destroy the body using the CollisionWorld::destroyCollisionBody() method because you want to reuse it in the future, you can disable a body temporarily using the CollisionBody::setIsActive(false) method. This method will remove the collision shapes of the body from the broad-phase collision detection. Therefore a body that is inactive won't be able to collide or be tested for raycasting. This body is still part of the world but is not simulated anymore. I think that might be the issue. It seems that you manually called the CollisionBody::updateBroadPhaseState() method on this body which will try to update the broad-phase state of each collision shape of this body but they are not part of the broad-phase anymore because the body is deactivated. |
|
But we have this issue also with your stock RP3D allocator branch. Just to mention. However if it happens again I will try to gather more information. |
|
Ok I have found that in the CollisionBody::updateBroadPhaseState() method I was checking for broadPhaseId != 1 before trying to update the broad-phase but this check was missing from the RigidBody::updateBroadPhaseState() version of the method. This is now fixed in the master and allocators branches. Could you please pull this branch and let me know if you still observe the issue or not ? |
|
Nice!!! Will test tomorrow at the latest. |
|
Hi Daniel. we are like testing a day now and had no issues with RP3D so far. Ill keep you updated. I think you can close this issue end of the week if nothing pops up. Many thanx! |
|
Ok that's good news. Thanks for the feedback. |
|
Hi, we had 2 asserts today. No backtraces yet. I have a bug in Console logging that's why they are missing. Sorry. Need to fix that. Assertion failed! Assertion failed! Hmm. Not sure if this is still the right place to post these. Just tell me how to proceed please. |
|
Maybe another multithreading issue. I will check. But maybe you have an idea too. |
|
No problem to post these here. I also suspect a multithreading issue. The Map.h error is very similar to the one you had few days before with the Set.h error. |
|
Have you been able to fix the issue ? |
|
Hmm. We have not seen it another time. I guess you can just close this issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I have enabled assertions recently in our game and hit an assertion, looks like a possible memory corruption to me if assertions are disabled.
The assertion is hit at:
It happens when trying to check if a player can spawn using this logic:
Any ideas? We had a related bug before but you fixed it.
Many thanx and
Best regards
Andreas
The text was updated successfully, but these errors were encountered: