AccessViolationException in StepSimulation()

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Unzip the attached file
2. Load the BulletTest solution into VS2012
2. Run it
3. At world time 1.433 the AccessViolationException is thrown

What is the expected output? What do you see instead?

The simulation ought to compute all time steps.  Instead an exception was 
thrown.

What version of the product are you using? On what operating system?
BulletSharp.dll generic 2.81.0.0
Windows 7 64-bit

Please provide any additional information below.

I searched for similar problems, and found these links:
https://code.google.com/p/bulletsharp/issues/detail?id=40
https://code.google.com/p/bulletsharp/issues/detail?id=33
http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=8180

I tried various ways of retaining as many references to objects as I could to 
no avail.

In addition, I have noticed the following:

 - Changing the ball count changes the behaviour. Reducing the count typically reduces the chance of a crash. e.g. changing it to 5000 allows it to finish.
 - I had to increase the count from 5000 to 15000 when creating a console application. The real application I am using it in also visualizes the simulation and produces the exception with fewer bodies.
 - Change the friction also changes the behaviour. Higher friction would reduces interactions, which I would assume reduces the chance for this error.

Original issue reported on code.google.com by p...@eveandphil.com on 18 Apr 2013 at 12:31

Attachments:

• BulletTest.7z

[GoogleCodeExporter]

The program seems to allocate a whole bunch of unmanaged memory, which suggests 
that Bullet is generating lots of new contact points as the simulation 
progresses. I think what's happening is that you're hitting the heap memory 
limit for 32-bit applications. At 1.433 seconds the memory usage is at around 2 
GB.

You can try to compile Bullet&BulletSharp as 64-bit or duplicate the scenario 
in C++ to check if it's really an unmanaged issue.

Original comment by andres.traks on 18 Apr 2013 at 6:38

[GoogleCodeExporter]

Yup, confirmed. The 64-bit version peaked at about 5.6 GB of memory usage, so 
you definitely need that. The simulation got very slow after a few seconds as 
you'd expect with so many collision objects, so I only waited 6 seconds of game 
time, but I expect that it would proceed without error.

It's a pretty interesting test case for Bullet&BulletSharp though. :)

Original comment by andres.traks on 23 Nov 2013 at 7:43

• Changed state: WontFix

[GoogleCodeExporter]

Sorry for not replying for so long. Thank you very much for following up on 
this. I never did get around to doing a 64-bit build, as much as I wanted to.

It was a really interesting exercise. I was investigating it for a rough 
simulation of granular material on a conveyor, as a first pass before 
performing simulations with more physically based simulations, something 
LIGGGHTS (http://cfdem.dcs-computing.com/?q=OpenSourceDEM) does very well.  The 
interesting part is LIGGGHTS is hundreds of times slower, but uses much much 
less memory. What was very interesting though is I was getting very grossly 
similar behaviour from bullet sharp, and I think if I got the memory 
consumption under control it would be a useful tool.

So yes - I agree, a very interesting test case! I can produce any number of 
similar of scenarios should you be interested.

Thanks again!

Original comment by p...@eveandphil.com on 26 Nov 2013 at 11:30

[GoogleCodeExporter]

There is now a 64-bit release if you ever want to play with it:
https://code.google.com/p/bulletsharp/downloads/list

Original comment by andres.traks on 25 Dec 2013 at 11:08