Good morning,
Robert Osfield wrote:
The only variable in DeleteHandler that wasn't initialized was
_currentFrameNumber, but the Valgrind error doesn't suggest this.
I've fixed this error though, its unlikely to have much baring on
things though as the frame number of overwritten on the first frame.
This fix is now checked in.
Interestingly enough, this does make that valgrind error go away...
Well, another uninitialized variables bites the dust (even though it
only lived in that state for one frame)! :)
Paul
Robert.
On 7/9/07, Paul Melis <[EMAIL PROTECTED]> wrote:
Hello Robert,
Robert Osfield wrote:
> This is most certainly a bug, which I'm delighted you've picked up -
> its now fixed and checked in to SVN ;-)
>
> The problem is that _threadsRunning was an uninitialized variable,
> something I obviously missed in dev of 2.0, probably due to this
> variable being a later addition. I've just gone through
> CompositeViewer and can't spot any more uninitialized variables. I'll
> go a double check the other Viewer classes as well.
I just ran valgrind on the osgcompositeviewer example as an experiment
to see if it would have caught this one and indeed, on the version
_before_ you checked in the above change Valgrind reports the variable
as not being initialized. After running a few of the examples under
valgrind the only error consistently reported is one in DeleteHandler:
==6510== Conditional jump or move depends on uninitialised value(s)
==6510== at 0x40E2D9D: osg::DeleteHandler::flush()
(DeleteHandler.cpp:92)
==6510== by 0x44FC5AE: osgViewer::Viewer::advance(double)
(Viewer.cpp:1820)
==6510== by 0x44FC145: osgViewer::Viewer::frame(double)
(Viewer.cpp:1780)
==6510== by 0x44FC249: osgViewer::Viewer::run() (Viewer.cpp:762)
==6510== by 0x804CD80: main (osghud.cpp:286)
The relevant section is
ObjectsToDeleteList::iterator itr;
for(itr = _objectsToDelete.begin();
itr != _objectsToDelete.end();
++itr)
{
if (itr->first > frameNumberToClearTo) break; ///
<-------------- this is line 92
deletionList.push_back(itr->second);
itr->second = 0;
}
I've added some debug prints showing the itr->first value but it seems
to be o.k.
Perhaps this one is a false alarm, but I thought I'd share it as you
might have a better overall view of what could be going on here...
Paul
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
