[ODE] Re: ALLOCA

[Olivier Michel]

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