[ODE] Segfaulting ODE with too many objects -- ALLOC vs MALLOC

[Kyle Hubert]

On 9/30/06, Jon Watte (ODE) <hplus-ode at mindcontrol.org> wrote:
> alloca() is a LOT faster than malloc(), because it doesn't have to worry
> about locking and contention. This is especially true in threaded
> applications with heavy load.

Right. No disagreement. This is very true. It might be good to take
into consideration that those applications with a heavy load may also
want more than just 600 objects per scene. Programmers become angry
when they do apparently-legal things and get segfaults. Should I make
sure that all such bug reports should be directed to you? :)

> There already exists a contribution/patch that changes alloca to use
> malloc/free instead. You can use this if necessary and desired.

Yes, as I mentioned earlier, there is support for using a straight
malloc/free only in lcp.cpp and step.cpp. I do admit my particular
problem is in quickstep.cpp, which doesn't support the compile flag to
switch to malloc/free. Also, as you point out, malloc/free is slower,
so why would I want this?

> Btw: using cygwin on Windows just isn't the best way to develop a
> Windows application, because it doesn't support all things necessary to
> integrate well with Windows. I highly recommend using Visual Studio instead.

Unfortunately,  I'm not developing a Windows application. I'm stuck
working on a Linux application in Windows until I can convince work to
get me a real Linux box. Which, then I'll get to pound my head against
all the dll->so changes.

> Kyle Hubert wrote:
> > On 9/26/06, Kyle Hubert <khubert at gmail.com> wrote:
> >
> >> Is there a definable upper bound to the number of objects ODE can
> >> handle at one time? I seem to have the ability to run a simulation
> >> fine with N number of Geoms, but at N+1 the simulation segfaults with
> >> the error seen below.
> >>
> >
> > OK, so it appears that for dWorldQuickStep it calls SOR_LCP on line
> > 340 in quickstep.cpp for release 0.7. This function uses alloca to
> > find room for all the dReals and the IndexError structs. In my
> > particular case, there isn't enough room on the stack, since I'm
> > constrained to cygwin/Windows ulimit won't let me bump my stack.
> > Anyways, this brings me to a curious question.
> >
> > Why is everything on the stack? Is this to avoid having to keep track
> > of frees? I replaced the allocas with malloc/frees and everything
> > worked. Now I can have a lot more objects. Is this beneficial to
> > anyone else? I understand there would be a few more clock ticks of
> > overhead for the malloc function as well as free, but using the stack
> > is a little limiting.
> >
> > If I do change the behavior would anyone else appreciate this? I can
> > use a preallocated pool or even a freelist/realloc. Any of the old
> > tricks from the book, anything but just a stack allocation.
> >
> > With malloc/free we can even give concise errors that we are out of
> > heap and return, rather than segfaulting.
> >
> > Yes? Anybody?
> >
> > -Kyle
> > _______________________________________________
> > ODE mailing list
> > ODE at q12.org
> > http://q12.org/mailman/listinfo/ode
> >
> >
> >
>