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

Native code crash inside btRigidBody_btRigidBodyConstructionInfo_new2 #57

Open
smlehbleh opened this issue Jul 18, 2019 · 7 comments
Open

Comments

@smlehbleh
Copy link

Hi,
I'm getting a crash when I construct a RigidBodyConstructionInfo with the localInertia value value passed in.

From looking at: libbulletc/src/btRigidBody_wrap.cpp, it looks like that last parameter is coming in as a pointer but the C# wrapper isn't using ref.

I am for now working around it by avoiding that constructor and setting localInertia with the property interface.

@AndresTraks
Copy link
Owner

It should work whether or not the wrapper class uses ref.

Did you compile libbulletc yourself? I haven't tested extensively except for x64 and the MSVC compiler.

I suspect that there is something wrong with memory alignment. If Bullet is compiled with SSE support (BT_USE_SSE defined), then SSE instructions are used to copy values from one place to another. SSE instructions require both source and destination memory to be aligned to 16 bytes.

.NET does not guarantee that the localInertia parameter is aligned to 16 bytes in memory, so libbulletc copies the parameter to a temporary aligned variable (conversion.h). The destination will be btRigidBodyConstructionInfo, which should also be aligned to 16 bytes with the ALIGNED_NEW macro.

I'm not sure if the ALIGNED_NEW definition should have the BT_USE_SIMD_VECTOR3 condition.
Can you try removing it in main.h?

...
#if defined(BT_USE_SSE)
#define ALIGNED_NEW(targetClass) ALIGNED_NEW_FORCE(targetClass)
...

@smlehbleh
Copy link
Author

Hi Andres,
Thanks for the response. I've tried commenting out the BT_USE_SIMD_VECTOR3 condition in main.h
Unfortunately it doesn't fix it - also according to my git client, the end libbulletc dll was identical.
I can't figure out where the BT_USE_SSE define is set/unset.

I am compiling libbulletc myself - i ran cmake on the libbulletc root, which generated a makefile which I just called - but I didn't specify any options so I'm not sure if its building with the correct defines.

I've just added some code which calls: btRigidBody_applyCentralForce and this suffers the same native crash.

@AndresTraks
Copy link
Owner

BT_USE_SSE is defined in bullet3\src\LinearMath\btScalar.h, but only if Bullet thinks that the compiler and the target platform support SSE.

There is this comment in btScalar.h:

//BT_USE_SSE_IN_API is enabled on Mac OSX by default, because memory is automatically aligned on 16-byte boundaries
//if apps run into issues, we will disable the next line
#define BT_USE_SSE_IN_API

If you are on a Mac, you could try commenting out that line. This should make Bullet use SSE internally, but disable SSE at the API boundary. I don't have an Apple environment available to test.

If that doesn't work, try forcing alignment in BulletSharp's main.h:

#if 1 // defined(BT_USE_SSE)
#define ALIGNED_NEW(targetClass) ALIGNED_NEW_FORCE(targetClass)

@AndresTraks
Copy link
Owner

AndresTraks commented Aug 11, 2019

There was an alignment fix in Bullet just before your issue:
bulletphysics/bullet3@448f0b8

Maybe that broke something. Or if you happen to have an older version of bullet3, maybe it fixed this problem.

@thatcosmonaut
Copy link
Contributor

I can confirm this issue is still a problem on OSX. I tried all the solutions listed in this thread and none of them work, I get a native crash as soon as I call a Rigidbody method that takes a Vector3.

@AndresTraks
Copy link
Owner

I still don't have an OSX environment to develop on.
Maybe you can get more detailed information with a debug build?

@thatcosmonaut
Copy link
Contributor

Unfortunately mono native traces are not particularly detailed... I will try to rig up an xcode project at some point and see if the debugger can tell us anything.

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

No branches or pull requests

3 participants