[Resolved] Investigating potential crash of NewtonCreate.

[AntonSynytsia]

One of the users of my newton dynamics physics SDK wrapper informed me that the wrapper crashes every time it starts. After pinpointing the location of the crash we realized that the crash comes after calling NewtonCreate(), which is very unusual. It works on my Windows 10 platform and on the platforms of other Windows 10 users, but calling NewtonCreate() crashes on the contactee's Windows 10. The contactee also informed me that Minecraft crashes on his system too, which may indicate that there is something wrong with his windows 10 system. However, one of my initial versions of the wrapper didn't crash on the contactee's system.

In my new and previous wrapper, I defined DG_USE_THREAD_EMULATION as threads are not stable on windows... Unlike on my previous wrapper, on my new wrapper I have some defines modified. Here is the list of modified defines:

dgContact.h: DG_MAX_CONTATCS from 128 to 4096
dgBroadPhase.h: DG_BROADPHASE_MAX_STACK_DEPTH from 256 to 4096
dgWorldDynamicUpdate.h: DG_MAX_SKELETON_JOINT_COUNT from 256 to 4096
dgWorldDynamicUpdate.cpp DG_PARALLEL_JOINT_COUNT_CUT_OFF from 256 to 4096

There are many other differences between the previous and the new wrapper, like the previous uses Newton 3.13 and a lot less developed than the new wrapper, which uses of the most recent builds of 3.14.

I was wondering what are the potential reasons that calling NewtonCreate could lead to a crash on a windows machine. Just looking one level deep into the function, NewtonCreate is a place where memory allocation occurs. I was wondering maybe it could be related to the fact that increasing values of some defines demands an increase in the RAM usage, which might surplus the limit of the RAM memory available on the contactee's Windows 10 system and lead to a crash. Does anyone have any implications of what are the potential reasons that calling NewtonCreate could result in a crash on a Windows 10 operating system?

I would change the defines back to original values and see if it still crashes on the contactee's machine, but I still want some descent feedback and insight on this (if anyone has any).

Thanks,
Anton

[Julio Jerez]

dgContact.h: DG_MAX_CONTATCS from 128 to 4096
dgBroadPhase.h: DG_BROADPHASE_MAX_STACK_DEPTH from 256 to 4096
dgWorldDynamicUpdate.h: DG_MAX_SKELETON_JOINT_COUNT from 256 to 4096
dgWorldDynamicUpdate.cpp DG_PARALLEL_JOINT_COUNT_CUT_OFF from 256 to 4096

that's a big mistake, by doing that you make the stack vey large.
there default values are good the way that are already.

On the windows 10 crash, I have a window 10 system at work, and I do get a crash on start in release mode in 32 bit. all other mode work fine.
the crash is does not gives me any information at all, so I do no know what could be. I was guessing is was related to wxwidged, and open GL.

I will set break point on in the Create function and see if I can have more information on the crash that I see. Is your plug in 32 bit, could you try 64 bit just to see if it is the same problem.

[AntonSynytsia]

The crash occurs on both 32bit and 64bit versions of my wrapper on the contactee's Windows 10 machine.

The way I located the crash was by showing messageboxes before and after calling NewtonCreate. That way, the messageboxes interrupted the processing and gave me a way to determine at what point the crash occurs, which is when calling NewtonCreate. The messageboxes before calling NewtonCreate displayed, but the ones after calling NewtonCreate didn't display, which indicates that NewtonCreate caused the crash.

I will reduce the values back to original as you suggested. I was wondering that increasing them would improve stability, especially the DG_MAX_CONTATCS and DG_BROADPHASE_MAX_STACK_DEPTH.

[Julio Jerez]

I did not pay attention because I though it was some silly virus scanner no letting new app run.
but I am able to run in 64 bit, that is also estrange.

I will try adding printf tomorrow, maybe they are the same bug them.

[Julio Jerez]

Ok I found out what Is the problem I has with windows 10.

Visual studio has this option names Manifest, why basically is a signature of the executable and all its dependencies. This prevents malicious people from swapping DLL behind the back of application and adding viruses and stuff like that.

In visual studio the manifest can be embed in the binary of it can be a extra file.
some how in 32 bit release mode this is set to embed Manifest, but for some reason in window see it as a bad program.
Extremely enough other configuration has Manifest to not embed, so the run fine, but the release 32 was on and did not even load.
I set to off and the it words fine. can you please try that.

The option is found in: Options->Manifest Tool->Input Output->Embed Manifest.

That was the problem on my side, I do not know if this is the same on yours.
The reason I ignored was because in some places companies set Virus scanners to not let any authorized program to run, so I though that was the case.

[AntonSynytsia]

Thanks, I will adjust that option and see if the new version works on the contactee's Windows 10 os.
Meanwhile, before turning off the manifest, I placed additional checkpoint messageboxes that dissect the functions called during NewtonCreate and we were able to pinpoint the point of crash a little further and it occurs in dgWorld.cpp, line 308, which states the following:
dgCollision* const pointCollison = new (m_allocator) dgCollisionPoint(m_allocator);
This might indicate that the crash occurs when calling the dgCollisionPoint constructor. The source of the dgCollisionPoint constructor resembles the following (dgCollisionSphere.cpp, line 83):

Code: Select all

dgCollisionPoint (dgMemoryAllocator* const allocator)
   :dgCollisionSphere(allocator, 0x12344321, dgFloat32 (0.25f))
{
}

The second parameter, aka the signature, makes me suspect that it may be causing the crash, however, I don't even know how the signature can lead to a crash or what it even does. What I do know is that the crash occurs when calling this function, which I think requires some anticipation.

Other than that, I will disable the manifest and see if it works on the contactee's Windows 10 os.

[Julio Jerez]

the only way that can crash on this function
dgCollision* const pointCollison = new (m_allocator) dgCollisionPoint(m_allocator);

is if m_allocator was NULL, can you check if that is the case?

you may need to build it in debug mode, so that you can asset a breakpoint and check that m_allocator is not NULL;
you can a break point on this function

Code: Select all

NewtonWorld* NewtonCreate()
{
   TRACE_FUNCTION(__FUNCTION__);
   dgMemoryAllocator* const allocator = new dgMemoryAllocator();

   NewtonWorld* const world = (NewtonWorld*) new (allocator) Newton (dgFloat32(1.0f), allocator);
   return world;
}

an see if new dgMemoryAllocator(); is retirning a NULL pointer, that's the kind of stuff that may be OS depended.

[AntonSynytsia]

The m_allocator is not NULL/0/nullptr and allocator from new dgMemoryAllocator() is also not NULL/0/nullptr.

I placed more checkpoint messageboxes that dissect deeper into the constructors and functions called during dgCollision* const pointCollison = new (m_allocator) dgCollisionPoint(m_allocator);, and the crash occurs in dgCollisionSphere.cpp, in dgCollisionSphere::Init(dgFloat32 radius, dgMemoryAllocator* allocator) (line 68), after one of the TesselateTriangle functions are called. The TeselateTriangle function itself has some asserts. Maybe they are causing the crash.

Edit: The crash occurs while calling the first TesselateTriangle function.

[AntonSynytsia]

I was able to pinpoint and resolve the crash on the contactee's platform. The crash occurred in dgCollisionSphere::TesselateTriangle while computing the dot product between two vectors.

Looking at the source of the vector's dot product operator, I figured that the vector could be computed two ways: using DG_SSE4_INSTRUCTIONS_SET or using current functions of NewtonDynamics. The DG_SSE4_INSTRUCTIONS_SET define is by default defined in the dgTypes.h, line 102. I though maybe commenting out the DG_SSE4_INSTRUCTIONS_SET define would resolve the crash on the contactee's platform and it did.

I think the crash occured because the SSE4_INSTRUCTIONS_SET wasn't supported on the contactee's platform. I don't know the downsides of not relying on the SSE4_INSTRUCTIONS_SET, but disabling it resolves the crash.

In case anyone experiences an unknown crash when starting Newton, it could be related to the SSE4_INSTRUCTIONS_SET. Disabling it might resolve the crash.

[Julio Jerez]

the down side is nothing, I just though DG_SSE4_INSTRUCTIONS_SET most people by now had core duo or better cpus which all support dot product operations.