Native code crash at 'HACD_HACD_GetPartition'
maxilevi opened this issue · comments
This is the native call stack from WinDBG, I compiled libbulletc.dll as x64 and enabling thread locks. Does anyone have any clue on why this might be happening?
Any suggestions on how to debug this?
00000000`00cfe190 00007ffd`d348c266 ntdll!RtlReportCriticalFailure+0x56
01 00000000`00cfe2a0 00007ffd`d348c531 ntdll!RtlpHeapHandleError+0x12
02 00000000`00cfe2d0 00007ffd`d342a505 ntdll!RtlpHpHeapHandleError+0x5d
03 00000000`00cfe300 00007ffd`d343990d ntdll!RtlpLogHeapFailure+0x45
04 00000000`00cfe330 00007ffd`701e5658 ntdll!RtlFreeHeap+0x92b1d
**05 00000000`00cfe3d0 00007ffd`700c747d libbulletc!btGImpactCollisionAlgorithm_getPart1+0xe7c8
06 00000000`00cfe400 00007ffd`700c7b5d libbulletc!btConvexHullShape_getNumPoints+0x718d
07 00000000`00cfe450 00007ffd`700c7e36 libbulletc!btConvexHullShape_getNumPoints+0x786d
08 00000000`00cfe480 00007ffd`700c9f8d libbulletc!btConvexHullShape_getNumPoints+0x7b46
09 00000000`00cfe4b0 00007ffd`700b0fac libbulletc!btConvexHullShape_getUnscaledPoints+0x63d
0a 00000000`00cfe550 00007ffd`700b0cf6 libbulletc!btManifoldPoint_getUserPersistentData+0x7b0c
0b 00000000`00cfe610 00007ffd`700af144 libbulletc!btManifoldPoint_getUserPersistentData+0x7856
0c 00000000`00cfe650 00007ffd`7010d460 libbulletc!btManifoldPoint_getUserPersistentData+0x5ca4
0d 00000000`00cfe6a0 00007ffd`7010e84f libbulletc!HACD_HACD_GetPartition+0x6a0
0e 00000000`00cfe6f0 00007ffd`6775c0d5 libbulletc!HACD_HACD_GetPartition+0x1a8f**
0f 00000000`00cfe730 00007ffd`6775bfa5 0x00007ffd`6775c0d5
10 00000000`00cfe830 00007ffd`6775bf19 0x00007ffd`6775bfa5
11 00000000`00cfe870 00007ffd`6775ba53 0x00007ffd`6775bf19
12 00000000`00cfe8b0 00007ffd`6775b931 0x00007ffd`6775ba53
13 00000000`00cfe980 00007ffd`66c29e6e 0x00007ffd`6775b931
14 00000000`00cfe9b0 00007ffd`66992abe 0x00007ffd`66c29e6e
15 00000000`00cfeaa0 00007ffd`66990770 0x00007ffd`66992abe
16 00000000`00cfec50 00007ffd`c5f26da3 0x00007ffd`66990770
17 00000000`00cfed20 00007ffd`c5f26c58 clr!CallDescrWorkerInternal+0x83
18 00000000`00cfed60 00007ffd`c5f2751d clr!CallDescrWorkerWithHandler+0x4e
19 00000000`00cfeda0 00007ffd`c5fa1dac clr!MethodDescCallSite::CallTargetWorker+0xf8
1a 00000000`00cfeea0 00007ffd`c5fa1f96 clr!RunMain+0x1e7
1b 00000000`00cff080 00007ffd`c5fa1e8b clr!Assembly::ExecuteMainMethod+0xb6
1c 00000000`00cff370 00007ffd`c5fa1c84 clr!SystemDomain::ExecuteMainMethod+0x57c
1d 00000000`00cff980 00007ffd`c5fa1c02 clr!ExecuteEXE+0x3f
1e 00000000`00cff9f0 00007ffd`c5fa2034 clr!_CorExeMainInternal+0xb2
1f 00000000`00cffa80 00007ffd`c6917b2d clr!CorExeMain+0x14
20 00000000`00cffac0 00007ffd`c6b9a4cc mscoreei!CorExeMain+0x112
21 00000000`00cffb20 00007ffd`d32b4034 MSCOREE!CorExeMain_Exported+0x6c
22 00000000`00cffb50 00007ffd`d3403691 KERNEL32!BaseThreadInitThunk+0x14
23 00000000`00cffb80 00000000`00000000 ntdll!RtlUserThreadStart+0x21
The libbulletc functions that are referenced in the stack trace are independent, so either the stack is corrupt or WinDBG is confused.
To get more information, you should compile libbulletc, BulletSharp and your project in Debug mode. If you are using Visual Studio, you can go to your project settings -> Debug -> "Enable native code debugging". Also, in Tools -> Options -> Debugging -> General, uncheck "Enable Just My Code".
One way in which a crash could happen is if some Bullet object is explicitly disposed, but is still used by another object. For example, if a TriangleIndexVertexArray is disposed, but still used by a GImpactMeshShape. If Bullet then tries to access the TriangleIndexVertexArray, heap corruption can occur.
That is very useful, thank you