Possible bug in vehicle?
by Marc Hernandez · in Torque Game Engine · 01/07/2002 (12:28 am) · 3 replies
In Vehicle.cc(1204) there is a variable that is used without being initialized.
CollisionTimeout* sFreeTimeoutList;
CollisionTimeout* next = walk->next;
walk->next = sFreeTimeoutList;
sFreeTimeoutList = walk;
walk = next;
Any chance we could compile cleanly at warning level 4? If we have a StdAfx.h included first in every .cc and put a few (annoying but necessary) pragmas to turn off the so called warning that come up (4514 etc) we should be able to.
This means typing a few more lines for thing, like the occasional 'f' on floating point numbers and some thought on the sign of things. I also modified the math lib to use ____f functions like sinf instead of sin.
CollisionTimeout* sFreeTimeoutList;
CollisionTimeout* next = walk->next;
walk->next = sFreeTimeoutList;
sFreeTimeoutList = walk;
walk = next;
Any chance we could compile cleanly at warning level 4? If we have a StdAfx.h included first in every .cc and put a few (annoying but necessary) pragmas to turn off the so called warning that come up (4514 etc) we should be able to.
This means typing a few more lines for thing, like the occasional 'f' on floating point numbers and some thought on the sign of things. I also modified the math lib to use ____f functions like sinf instead of sin.
#2
01/18/2002 (10:45 pm)
That uninitialized variable thing has been bubbling around down near the bottom of my list of things to check. I promise if I get around to looking at it I'll pop back in here, although of course I wouldn't be averse to someone else figuring out what's up first. :-)
#3
It turns out that there is a static var named sFreeTimeoutList, initialized to zero, as a public field of ShapeBase. So vehicle.cc should be able to access that (ShapeBase is the parent of Vehicle). If the code had used that static var instead of redeclaring sFreeTimeoutList inside that little block, then the compiler wouldn't complain. And the code would look like the timeout-list-walking code that occurs in various places in shapeBase.cc.
Although I don't know what this list of structures is for, I have to say that removing that local declaration of sFreeTimeoutList appears to make a lot more sense. After running the loop you would then have the list of structures pointed to by the static var sFreeTimeoutList (and prepended to any existing list there), rather than the previous version of the code which seems to give them all a free ticket to Memoryleaksville.
The code probably would still function without this fix, since those structs get allocated if the code that needs them can't recycle them from the freelist (in fact that's the way the whole process gets bootstrapped), but still, memory leak bad. Anyone wanna check me on this?
Too bad the CVS history for that file got horked when it was moved into the vehicles subfolder.
01/25/2002 (5:02 pm)
Took a brief look at this to give my brain a break from something else.It turns out that there is a static var named sFreeTimeoutList, initialized to zero, as a public field of ShapeBase. So vehicle.cc should be able to access that (ShapeBase is the parent of Vehicle). If the code had used that static var instead of redeclaring sFreeTimeoutList inside that little block, then the compiler wouldn't complain. And the code would look like the timeout-list-walking code that occurs in various places in shapeBase.cc.
Although I don't know what this list of structures is for, I have to say that removing that local declaration of sFreeTimeoutList appears to make a lot more sense. After running the loop you would then have the list of structures pointed to by the static var sFreeTimeoutList (and prepended to any existing list there), rather than the previous version of the code which seems to give them all a free ticket to Memoryleaksville.
The code probably would still function without this fix, since those structs get allocated if the code that needs them can't recycle them from the freelist (in fact that's the way the whole process gets bootstrapped), but still, memory leak bad. Anyone wanna check me on this?
Too bad the CVS history for that file got horked when it was moved into the vehicles subfolder.
Torque 3D Owner Phil Carlisle
Just a warnin.
Phil.