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

[Jon Watte]

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
>
_______________________________________________
ODE mailing list
ODE at q12.org
http://q12.org/mailman/listinfo/ode