Hello Pablo,

Pablo Carneiro Elias wrote:
> Hi,
> 
> thanks for the help... I've finally found the problem.. I've posted a few
> messages about some children node removal problem.. the issue in my last
> mail about init / exit was thought as having something to do with the node
> removal problem.. but it hasn't .. the problem was simple: The
> SimpleSceneManager class has a function named 'setHighlight' that, as the
> name says, sets a node as highlighted and draws a visible bounding box
> around it. When I removed the node from the scene its reference seemed to be
> set to count zero and it got deleted (?), but the simplescenemanager kept a
> reference to it ( invalid, any how ).... So, when the scene was being
> redrawed, the scenemanager accessed this node and the program crashes...
> so, the solution was to simple set the hightlighted node to null before
> removing it from the scene.... scenemanger->setHighLight( OSG::NullFC )...
> 
> But my question is: why does the scenemanager reference (NodePtr) got
> invalid .. if the scenemanager had a reference to the node, the node
> shouldn't be deleted...(?) so, it seems that the scenemanager setHighLight
> isn't increasing the reference count of the given NodePtr passed as
> parameter.... I'm not sure if it should be increased or not (I'm mean, if it
> is the right manner to avoid crashing)... if the reference got increased,
> the node whould stay as a child of the scenemanager class. In the other
> hand, if its reference is not increased, it goes against the reference
> counting principle (?)... to count all references and never delete it before
> it get to zero and automatically deletes it when it does....

well, it was a bug in the simple scene manager that should have used a 
NodeRefPtr instead of a plain NodePtr for its _highlight member. I fixed 
it, so the reference counting should be correct now. However, if you 
remove the node that has the highlight you still should call 
setHighlight(NullFC) for otherwise the geometry that does the 
highlighting will remain visible. I can not really think of a way we 
could automate this in OpenSG easily.
Thank you for tracking down and reporting this issue,

        Carsten

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to