[ODE] Allocation problem?

[Jon Watte (ODE)]

You can absolutely implement dALLOCA without leaking. The easiest thing 
to do is to re-use the existing blocks, and only grow when needed -- 
this doesn't "leak" although it may lead to "growing store" problems (it 
will also need an atexit() to free the data to avoid confusing leak 
checkers).

dFREEA is not needed, and should not be added, because it would be a no-
op, so code paths would get in there that didn't do the right thing in
exceptional cases and nobody would know.

The thing you need to do to make sure that a dALLOCA replacement works 
is to figure out when it's safe to clean up the previous allocations and 
re-use the pointer. At the entry of all dWorld step functions seems like 
as good a place as any.

Cheers,

			/ h+




Geoff Carlton wrote:
> 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
>>   
> 
>