[ODE] Problems in QuickStep

Russell Bartley russellbartley at kromestudios.com
Mon Jun 25 22:53:29 MST 2007


I had a problem in the function QuickStepper that I think might be a memory overwrite bug. I could be wrong tho.


At the top of Quickstepper, the number of constraints are calculated and put into the variable m.

Each joint is quizzed on the number of constraints via the function getInfo1()

Now I've only been testing this on Universal joints, so it may be different for other joints. 

The getinfo1() function on a universal joint maps to universalgetinfo1()

Inside of this universalgetinfo1() function the number of constraints is filled out into the dxJoint::Info1.m variable.

This value can be from 4 to 6. 

it starts at 4, and  If (j->limot1.fmax > 0) and hence (constraint1 == true) it will be incremented by 1

If (j->limot2.fmax > 0) and hence (constraint2 == true) it will be incremented by 1

then later on in QuickStepper, the function joint->getinfo2() is called, which calls the function dxJointLimitMotor::addLimot() twice.

This function modifies the values in the joint based off the row index passed in, which in the first call to dxJointLimitMotor::addLimot() row equals 4. The first call returns a value to indicate if more rows are needed, which is used by the second call to addlimot() as the row index to update.

The criteria to work out how many rows are needed inside of addlimot() are based off wether the (limot.fmax > 0) AND wether the limot.limit is non zero.

This is different to the original calculations of how much memory wouldbe required by the earlier calls to universalgetinfo1().

This means that occasionally these criteria would be different, and underestimate the required memory needed from the getinfo1() function. This resulted in the calls to addlimot() modifying memory after the allocation (which in this case I believe would be the jb array?)


I modified getinfo1 to calculate the m value based off not only the fmax > 0 test, but also the limit != 0 test. This seemed to fix my bug.

Is this a bug that has been in ODE for a long time that needs to be fixed or have I made a mistake somewhere?






This message and its attachments may contain legally privileged or confidential information. This message is intended for the use of the individual or entity to which it is addressed. If you are not the addressee indicated in this message, or the employee or agent responsible for delivering the message to the intended recipient, you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments, which does not relate to the official business of the sending company must be taken not to have been sent or endorsed by the sending company or any of its related entities. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ode.org/pipermail/ode/attachments/20070626/3371150f/attachment.htm


More information about the ODE mailing list