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

[Simon Barratt]

>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.

Another benefit of using a reusable stack on the heap is that you can
eliminate the dSetZero's by simply wiping whatever you use in your stack
for that step.. 

So you'll do all your alloca's into your new stack, use up say 10k of
space and then the stack system is refreshed by zeroing the whole thing
and setting the pointer back to the start of the stack.. Voila no more
stack overflows, redundant dSetZero's and a speedup :)

--
Simon Barratt, Lead Coder / PR guy, Pineapple Interactive Ltd
e: barog at pineapple-interactive.com
w: www.pineapple-interactive.com
t: +44 (0)1274 480185 

-----Original Message-----
From: ode-bounces at q12.org [mailto:ode-bounces at q12.org] On Behalf Of jon
klein
Sent: 12 February 2004 13:08
To: aspirin at ntlworld.com
Cc: ode
Subject: Re: [ODE] SIGSEGV in dSolveLCP() at ode/src/lcp.cpp:1137


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


_______________________________________________
ODE mailing list
ODE at q12.org
http://q12.org/mailman/listinfo/ode