Freeze / AccessViolationException when calling CollisionShape.GetAabb()

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a CollisionShape
2. Call CollisionShape.GetAabb(). It should work as expected.
3. Call CollisionShape.GetAabb() again. The program will either freeze or 
thrown an AccessViolationException.

If using a debug build of BulletSharp then you can skip step 2 because it 
happens on the first call instead.

What is the expected output? What do you see instead?
I expect the function to always return AABB extents instead of freezing or 
throwing an AccessViolationException.

What version of the product are you using? On what operating system?
I've reproduced the issue using the following versions:
- BulletSharp 2.82 (Release Generic)
- BulletSharp r626 + Bullet r2709 (Release Generic)
- BulletSharp r626 + Bullet r2709 (Debug Generic)

Please provide any additional information below.
I've attached a test program that reproduces the issue.

Here's information about the AccessViolationException:
    AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
       at delete(Void* )
       at BulletSharp.CollisionShape.GetAabb(Matrix t, Vector3& aabbMin, Vector3& aabbMax) in d:\programming\libraries\bullet physics\bulletsharp-r626-bullet-r2709\bulletsharp\src\collisionshape.cpp:line 261
       at BulletSharp_Tests.GetAabbTest.Main() in D:\Programming\Custom\BulletSharp Tests\GetAabb Test\GetAabbTest.cs:line 17
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()

When I run the test using a debug build of BulletSharp I get several failed 
assertions the first time I call CollisionShape.GetAabb():
    Assertion 1:
        Debug Assertion Failed!

        Program: ...arp Tests\GetAabb Test\bin\Debug\BulletSharp Tests.vshost.exe
        File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgdel.cpp
        Line: 52

        Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
    Assertion 2:
        Debug Assertion Failed!

        Program: ...arp Tests\GetAabb Test\bin\Debug\BulletSharp Tests.vshost.exe
        File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c
        Line: 1322

        Expression: _CrtIsValidHeapPointer(pUserData)
    Assertion 3:
        Debug Assertion Failed!

        Program: ...arp Tests\GetAabb Test\bin\Debug\BulletSharp Tests.vshost.exe
        File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c
        Line: 1328

        Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

Original issue reported on code.google.com by shiny....@gmail.com on 3 May 2014 at 8:55

Attachments:

• GetAabbTest.cs

[GoogleCodeExporter]

The AccessViolationException is likely because of misaligned btVector3 
allocations. SSE instructions require that data be aligned to 16 bytes. I've 
added code to make sure the allocations are correct in r628. Can you try it?

Original comment by andres.traks on 6 May 2014 at 4:17

• Changed state: Started

[GoogleCodeExporter]

This is related to issue #44.

Original comment by andres.traks on 6 May 2014 at 5:21

[GoogleCodeExporter]

You're really on top of things, aren't you? I don't regret having chosen 
BulletSharp at all.

However, it's not fixed quite yet.

If I comment out line 261 of CollisionShape.cpp ('delete tTemp;') it runs fine, 
but that of course introduces a memory leak. Replacing it with 
'ALIGNED_FREE(tTemp);' fixes it as well, but whether that's proper use of the 
macro is beyond me.

Original comment by shiny....@gmail.com on 6 May 2014 at 5:54

[GoogleCodeExporter]

Yep, ALIGNED_NEW needs to match ALIGNED_FREE and "new" needs to match "delete". 
Fixed in r629.

ALIGNED_NEW allocates a larger "smart" block of memory to make sure that data 
can be put on a 16-byte memory boundary. ALIGNED_FREE knows how to delete such 
a block.

Blocks allocated with "new" often just happen to be aligned and won't cause a 
crash in SSE code. So it's hard to say when ALIGNED_NEW/ALIGNED_FREE is 
necessary. It's also a little slower than the simple new/delete. Now all 
allocations are aligned just in case.

Original comment by andres.traks on 6 May 2014 at 8:13

[GoogleCodeExporter]

r629 is working flawlessly on my end.

Original comment by shiny....@gmail.com on 7 May 2014 at 12:29

[GoogleCodeExporter]

Cool. Thanks!

Original comment by andres.traks on 7 May 2014 at 7:00

• Changed state: Verified