[ODE] Allocation problem?

[Geoff Carlton]

It would be interesting to revisit this after 0.6, and fix it once and 
for all.

I had a look through the previous postings .  The posted patch, which 
mallocs if "full" would appear to leak memory, unless of course FREEA 
was added for every ALLOCA call.  In general that sort of solution looks 
the right way to go though.

Geoff

jon klein wrote:
>
> On Jun 7, 2006, at 12:28 PM, Jon Watte (ODE) wrote:
>
>> This already got implemented once AFAICR. There was a big discussion WRT 
>>
>> the overhead of malloc() vs the overhead of a linear allocator vs 
>>
>> whether there should be one big block or on-demand allocated small 
>>
>> blocks, vs static block re-use, ...
>>
>>
>> Thinking about it: did that ever actually make it into the codebase? If 
>>
>> it did, then the dALLOC failing could be because of some heap 
>>
>> corruption, instead of running out of stack.
>>
>
>
> I believe this issue has been coming up over and over again, literally
> for a couple of years, and I believe a fix is still not in the code base.
>
> I've been using a modified version of the patch outlined here:
>
> http://q12.org/pipermail/ode/2004-June/013276.html
>
> My modification is shown here (in the quoted text):
>
> http://q12.org/pipermail/ode/2004-June/013277.html
>
>
> Personally, I feel that fixing this is extremely important.  Using 
> alloca, even with an increased stack size, adding objects into a 
> simulation will eventually cause ODE to crash.  Though this may work
> fine for applications in which the user knows ahead of time how many 
> objects can be created, it's really not acceptable for an application
> which allows runtime creation of arbitrary objects (which is what I 
> used ODE for -- http://www.spiderland.org/breve ).
>
>
> - jon klein
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.8.3/358 - Release Date: 7/06/2006
>