-
-
Notifications
You must be signed in to change notification settings - Fork 221
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
HeapAllocator is not allocating pointers with 8 byte alignment #239
Comments
Hello, Yes the library has been tested on 64-bits (and currently developed on 64-bits). All the allocators of the library are using the DefaultAllocator specified here. As you can see this one is simply using std:malloc() for all allocations. The alignment returned by this method might be different on your system. What errors do you have exactly? What system are you using? |
This is on macOS 11 and Xcode with memory diagnostics turned on. Yes the initial pool is aligned but subsequent 'allocations' within the pool are not necessarily aligned depending on what the previous allocated size was. (HeapAllocator::splitMemoryUnit) Making requested size a multiple of 8 bytes in HeapAllocator::allocate fixes the alignment problem. At least initially to just init the library. Haven't got any further yet. I added this line after the initial size checks in HeapAllocator::allocate() More issues may or may not come up as I start using it. |
Overall I want to say Thank you for RP3D. It looks a lot more light weight and easier to understand than Bullet, which I appreciate. Based on the demos I have a feeling Bullet has better performance but overall simpler code matters too. |
More problems. This time it looks like it could potentially be a serious bug. In is causing |
Unfortunately, as I suspected, fixing the alignment problems require a lot of changes and/or good knowledge of how the library works, so at this point I have to conclude that for my needs it's a no go. |
You are right. I will need to fix those alignment issues for the next version of the library. |
This is now fixed in version v0.10.0 of the library. |
This is causing tons of memory errors right away just trying to create PhysicsCommon.
Has this library been tested on 64-bit at all?
The text was updated successfully, but these errors were encountered: