[ODE] SIGSEGV in dSolveLCP() at ode/src/lcp.cpp:1137

[Olivier Michel]

Actually, I am doing very interactive simulations and the crash occured 
only under some circumstances (when two complex humanoid robot colliding 
each other). The performance drop seems to me very acceptable (however, 
I didn't yet replaced all the stack allocations by dynamic allocations). 
Moreover, I believe a first implementation of dynamic allocation could 
be based on the standard malloc/free and could very easily be changed to 
more efficient functions in the future (as in glib where g_malloc/g_free 
are said to be more efficient than their standard malloc/free counterparts).

So, I will be waiting for the green light from Adam to get started with 
this patch (conditional compilation to get dynamic memory allocation).

A nice alternative could be, in the case of dSolveLCP(), to check the 
value of n and to make dynamic allocation only if n is bigger than a 
predefined value (in my case ODE crashed for n > ~300). However, this 
might be tricky...

-Olivier

jon klein wrote:

>
> On Feb 12, 2004, at 6:56 AM, Adam D. Moss wrote:
>
>> I'm quite interested.  This is probably useful for non-realtime
>> complex systems that insist on using StepSlow; it's also essential
>> for any platforms that don't have alloca(), though I do suspect that
>> the fairly massive heap churn could render it unpleasant in those
>> situations.  What do other people think?
>
>
> I have been using this solution for a while with real-time
> simulations and the performance penalty has been negligible.
> For me, it's a small price to pay to have confidence that the final
> simulation will be stable.
>
> I'm dealing with simulations in which number of objects, joints,
> interactions and other factors are not known at compile-time and
> are not known at initialization-time.  This makes it difficult
> for me to pick a stack size or otherwise try to design limited
> memory use into the simulation.
>
> Ultimately, yes, a reusable stack on the heap would solve these
> problems as well, with less overhead.  But I don't know that
> anybody's written one yet, and in the meantime, malloc/free
> is very useful.
>
> - jon klein