[ODE] Access Violation in ODE - solution/workaround

[DjArcas]

Right. The problem hasn't been solved, but it has been sidestepped.

Here is the code as it, from inside STEP.CPP:

dSolveLCP (m,A,lambda,rhs,residual,nub,lo,hi,findex);

// OLD WAY - direct factor and solv

/

// // factorize A (L*L'=A

//# ifdef TIMIN

// dTimerNow ("factorize A")

//# endi

// dReal *L = (dReal*) ALLOCA (m*mskip*sizeof(dReal))

// memcpy (L,A,m*mskip*sizeof(dReal))

//# ifdef FAST_FACTO

// dFastFactorCholesky (L,m); // does not report non positive definitenes

//# els

// if (dFactorCholesky (L,m)==0) dDebug (0,"A is not positive definite")

//# endi

/

// // compute lambd

//# ifdef TIMIN

// dTimerNow ("compute lambda")

//# endi

// dReal *lambda = (dReal*) ALLOCA (m * sizeof(dReal))

// memcpy (lambda,rhs,m * sizeof(dReal))

// dSolveCholesky (L,lambda,m);



Now, if I comment out the new way, and uncomment the old way (using
dFactorCholesky instead of dFastFactorCholesky), it works fine.



Now, I don't even begin to pretend to understand what the hell is going on
in this code, but perhaps there's some sort of problem with the new
dSolveLCP function?


----- Original Message ----- 
From: "Nate W" <coding@natew.com>
To: "DjArcas" <djarcas@hotmail.com>
Sent: Thursday, June 26, 2003 9:25 AM
Subject: Re: [ODE] Access Violation in ODE


> On Thu, 26 Jun 2003, DjArcas wrote:
>
> > > > All the arguments seem valid, I've bunged up the size of the
stack...
> > > > and I'm totally lost as for where to go now.
> > >
> > > Values of bunge greater than about 8MB will be clamped to 8MB by the
> > > operating system, if you're under Windows.
> >
> > Really? well that's bloody useless then.
>
> It can certainly be a pain.  There was a little bit of talk about possibly
> revising the way ODE allocates memory so that it won't be limited by
> Windows' stack limit, but it hasn't happened.  Basically, every instance
> of alloca() would have to be replaced with a macro like:
>
> #ifdef WIN32
> #define fastalloc fastalloc_win
> #else
> #define fastalloc alloca
> #endif
>
> fastalloc_win() would have to mimic alloca, treating a big hunk of heap
> memory as if it was a stack.  There would also have to be a function call
> to reset the "stack" pointer, perhaps invoked at the end of dWorldStep.
> Not difficult, just tedious work.
>
> > > Any idea how many bodies and joints (including contact joints!) are
> > > present in the system when this problem happens?
> >
> > 2 cars, consisting of a box and 4 spheres each, a plane, and a big box
in
> > the world. Each sphere has a hinge2 joint, and probably 1 contact joint
with
> > the. And that's it. I'm trying to remove things and see if that isolates
the
> > problem.
>
> That doesn't sound like near enough to use up the whole stack.  You should
> be able to get something on the order of 50 joints and 50 bodies, maybe
> more, before running out of stack.
>
> It's worth keeping project files under source control as well as the
> source code itself, and roll back the project files when you're tracking
> down obscure bugs.  My app would crash when I tried to go up the directory
> tree in a file-open dialog box... but only when I tried to use a stack
> size of 10,000,000 or so.  Not only does Windows refuse to go over
> 8,000,000 (as verified by dumpbin.exe), but it penalized me with an odd
> bug just for trying.
>
> The more I write for Windows, the more I envy Linux developers. :-)  I
> just haven't found a Linux IDE that I like as much as MSVC7.  I'm sure
> it's just a matter of time though.
>
> -- 
>
> Nate Waddoups
> Redmond WA USA
> http://www.natew.com
>
>
>
>