[ODE] Re: ALLOCA

[Martin C. Martin]

He basically suggested a stripped down version of auto_ptr that works 
with arrays.

- Martin

Olivier Michel wrote:

> Hi,
> 
> It seems I missed something (actually the quoted text mentioned in the 
> [..] below didn't reached the list). I would be very curious to know how 
> to avoid the FREEA() macro... I may improve my patch with this idea...
> 
> -Olivier
> 
>> Jon Watte wrote:
>>
>>> Regarding ALLOCA, you might not need a FREEA() macro, if you 
>>> structure the
>>> macro something like so:
>>
>>
>> [..]
>>
>> True, I think that'd work nicely.  (I often forget that ODE
>> is in C++!)
>>
>> --Adam 
> 
> 
> 
> Jon Watte wrote:
> 
>> I'm concerned that using MALLOC would make it significantly slower.
>>
>> What I've found useful in these situations is to have a linear 
>> allocator -- alloca() is linear in its usage pattern. Thus, you can 
>> allocate a large block (megabytes?) up front, and you implement the 
>> functions as:
>>
>> char * block;
>> size_t top;
>>
>> void init_alloca()
>> {
>>  block = malloc( MAX_ALLOCA_SIZE );
>>  // maybe do something that aligns "block" on 16 bytes
>>  top = 0;
>> }
>>
>> void * alloca( size_t size )
>> {
>>  // round size to good alignment
>>  size = (size + 15) & -16;
>>  top += size;
>>  assert( top <= MAX_ALLOCA_SIZE );
>>  return block+top-size;
>> }
>>
>> void * freea( void const * ptr )
>> {
>>  top = min( top, (char const *)ptr - block );
>> }
>>
>>
>> Make 'em inline, and you're about as efficient as alloca() is, but you 
>> don't gobble the stack. The cost is that you have to define how deep 
>> you want to go up-front. Note that this implementation is branch-less 
>> (assuming "min" turns into a conditional move).
>>
>> At the cost of adding branches (which flush pipelines and cause stalls 
>> when mis-predicted), you could make it return malloc() memory if it 
>> runs out of pre-allocated memory, and free() the block if the pointer 
>> isn't in the range of [block, block+MAX_ALLOCA_SIZE). This would make 
>> it still "work" for large problems, albeit slower.
>>
>>
>> Cheers,
>>
>>             / h+
>>
>>
>> -----Original Message-----
>> From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of
>> Olivier Michel
>> Sent: Thursday, February 12, 2004 3:32 AM
>> Cc: ode
>> Subject: Re: [ODE] SIGSEGV in dSolveLCP() at ode/src/lcp.cpp:1137
>>
>>
>> Well, it works fine now. I patched the lcp.cpp file as follow:
>>
>> #define ALLOCA(x) malloc(x)
>> #define FREEA(a) free(x)
>>
>> and I added a FREEA() for each ALLOCA() call in the source code. Now 
>> my simulation never crashes (great!).
>> We could do the same for other files (step.cpp, matrix.cpp, etc.) and 
>> set up some #ifdef stuff so that the user can compile ODE in stack 
>> allocation of dynamic allocation mode.
>>
>> I volunteer to implement this patch if it will be integrated into the 
>> main ODE CVS trunk.
>>
>> Let me know what do you think about it.
>>
>> -Olivier
>>
>>
>> Olivier Michel wrote:
>>
>>  
>>
>>> Thanks for the replies. However, I cannot work around this problem:
>>>
>>> (1) I tryed increasing the heap size under Linux: "ulimit -s 
>>> unlimited" to increase the heap size from 8192 to unlimited, but that 
>>> didn't helped (might be ineffective).
>>>
>>> (2) I tryed to use dWorldStepFast1 instead of dWorldStep, but then 
>>> all my bodies are falling down breaking the joints I set. I set all 
>>> the masses to 1 to try to avoid this problem but it didn't change 
>>> anything (still collapsing the model).
>>>
>>> It seems the simulation works with fine dSolveLCP() when the n 
>>> parameter remains below ~200. However, when my two humanoid robots 
>>> hit each other (~44 bodies connected through joints), n reaches 384 
>>> and the SIGSEGV occurs...
>>>
>>> I will try to replace all the ALLOCA from lcp.cpp to dynamical 
>>> allocations / desallocations as it seems to be the only way to work 
>>> around this problem, isn't it ?
>>>
>>> If it works, may I contribute this alternative to the ODE cvs if this 
>>> is usefull for others ?
>>>
>>> -Olivier
>>>
>>> Martin C. Martin wrote:
>>>
>>>   
>>>
>>>> Search the docs for "stack," and you'll see at least two things you 
>>>> can do.
>>>>
>>>> - Martin
>>>>
>>>> Olivier Michel wrote:
>>>>
>>>>     
>>>>
>>>>> Hi there,
>>>>>
>>>>> I have a bug in my ODE simulation which occurs in ODE dSolveLCP() 
>>>>> function after a while and when two objects enter in collision, but 
>>>>> I don't understand why a SIGSEGV occurs while creating a stack 
>>>>> object in ode/src/lcp.cpp:1137. Here is what I get from gdb (under 
>>>>> Linux/woody):
>>>>>
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> [Switching to Thread 1024 (LWP 6180)]
>>>>> 0x0817333e in dSolveLCP (n=351, A=0xbfef1630, x=0xbfeef480, 
>>>>> b=0xbfeeff90,
>>>>>  w=0xbfeee970, nub=0, lo=0xbfff9af0, hi=0xbfff8fe0, findex=0xbfff8a54)
>>>>>  at ode/src/lcp.cpp:1137
>>>>> 1137      dLCP lcp 
>>>>> (n,nub,A,x,b,w,lo,hi,L,d,Dell,ell,delta_w,state,findex,p,C,Arows);
>>>>>
>>>>> How can the creation of a dLCP object cause a SIGSEGV ? Shall I try 
>>>>> to replace it by something like:
>>>>>
>>>>> dLCP *lcp = new dLCP(...);
>>>>>
>>>>> Any hint would be appreciated.
>>>>>
>>>>> -Olivier
>>>>>       
>>
>>  
>>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode