Assertion when moving from Linux to Mac OS X

[key...@googlemail.com]

Hi list,

i am a heavy ODE user for some years now. Originally, I developed my
applications on Linux (386 architecture). I have recently switch from
Linux to Mac OS X (Intel Core 2 Duo). The problem is the following.
When I take the exact same ODE code (making changes only to the
visualisation part), I get the following error message:

ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
_dNormalize4() [../../include/ode/odemath.h]

Asking the net, I found that this happens if the dimensions and
weights of the objects are not chosen with care. I do not think that
this applies in this case, as the code already worked on Linux.
Interestingly, I have this problem not only with my simulation, but
also with an ODE based simulator of a collaborator of mine.

I tried compiling with double and single precision, but it did not
change anything.

Has anyone encountered this problem before, or can give me some
advice? Any help is very welcome, as this is a serious issue for me.

Cheers,
Keyan

[AstralChild101]

Are you using the same version of ODE in linux and mac?

On Feb 16, 10:56 am, "key....@googlemail.com" <key....@googlemail.com>
wrote:

[key...@googlemail.com]

Hi,

thanks for the fast reply.

yes, its the same version, and also for different versions

0.9 - the version my collaborator uses
0.10.1 - the version i use for my simulator

cheers,
keyan

[AstralChild101]

Hello again,
I was thinking maybe you haven't used the dInitODE2(0); line before
initializing the world. I think ode from version 0.10 needs this line
or else it gives an error.
Other than that I have no idea.

On Feb 16, 11:49 am, "key....@googlemail.com" <key....@googlemail.com>
wrote:

[Danny Price]

I've not had any problems using ODE on OSX. This sounds like a precision problem. Are you using double precision?

[key...@googlemail.com]

hi,

i use the dInitODE() with the 0.9 version, and now also compiled the
first simulator against 0.10.1 using the dInitODE2(0), but no
success.

with the simulator that was previously linked against 0.10.1, i only
used the dInitODE.

a web research revealed that this has to do with bad values in
dimensions and mass of objects. with my 0.10.1 simulator i can use a
bad workaround, in which i increased the mass of the wheel of my
mobile robot by a magnitude of 10. this of course is not optimal, as
it means that i my results are not portable. for the simulator that
uses the 0.9 version, i am playing around with the masses for some
time now, but cannot achieve a setting that works.

could it be a compiler issue? 4.0 vs 4.2 vs 4.3, some compile options,
such as optimisation flags, architecture flags?

cheers,
keyan

[key...@googlemail.com]

hi,

thanks for the reply. yes, i am using double precision: here is my
configure setting:

./configure --with-x --with-drawstuff=OSX --enable-demos --enable-
shared --enable-release --enable-double-precision

cheers,
keyan

On Feb 16, 6:13 pm, Danny Price <deepblue...@googlemail.com> wrote:
> I've not had any problems using ODE on OSX. This sounds like a precision
> problem. Are you using double precision?
>

> On Mon, Feb 16, 2009 at 10:56 AM, key....@googlemail.com <

[Daniel K. O.]

key...@googlemail.com escreveu:

> ./configure --with-x --with-drawstuff=OSX --enable-demos --enable-
> shared --enable-release --enable-double-precision

First, "--enable-release" doesn't exist anymore; there's a
"--disable-asserts", that disables the internal asserts. Other
optimizations should be passed through CFLAGS, CXXFLAGS and LDFLAGS,
like usual for automake-based packages.

>>> visualisation part), I get the following error message:
>>> ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
>>> _dNormalize4() [../../include/ode/odemath.h]
>>> Asking the net, I found that this happens if the dimensions and
>>> weights of the objects are not chosen with care.

Actually, this is a pretty generic error. Normalization routines are
called from everywhere inside ODE; it can be caused by bad user data,
memory corruption, miss-compilation of buggy code (but I hope we fixed
all of it by now), single/double mismatch and so on. Your best bet is to
run your program in a debugger and let it catch the SIGABRT signal. Then
have a look at the stack backtrace to see which part of the code is
failing - and probably inspect the data too, watch out for infinity and NaN.

You might want to run configure as:

./configure --with-x --with-drawstuff=OSX --enable-demos --enable-shared
--enable-double-precision CFLAGS="-Wall -g3" CXXFLAGS="-Wall -g3"
LDFLAGS="-g3"

so you get useful information from the debugger. Running the program on
valgrind to check for memory corruption might be a good idea also.

--
Daniel K. O.
"The only way to succeed is to build success yourself"

[key...@googlemail.com]

Hi,

it seemed to be a problem with the compiler flags. at least with my
simulation, i do not have the problem anymore. with the other
simulator i am currently struggling with something else. i will
respond as soon as i have news.

for now, thanks a lot for the help.

cheers,
keyan

On Feb 17, 2:35 am, "Daniel K. O." <danielko.lis...@gmail.com> wrote:
> key....@googlemail.com escreveu:

[key...@googlemail.com]

hi,

solved, at least with ode 0.10.1 with both simulations. it seems that
the compiler flags were the problem.

thanks again for the help.

cheers,
keyan

On Feb 17, 3:19 pm, "key....@googlemail.com" <key....@googlemail.com>
wrote: