Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix children[] array not deleted in deleteNodeRecurs function. #288

Open
wants to merge 3 commits into
base: devel
Choose a base branch
from

Conversation

xinyiz
Copy link

@xinyiz xinyiz commented Mar 23, 2020

Fix issue where deleteNode children == __null assertion fails due to children[] array not deleted in deleteNodeRecurs function (https://github.com/OctoMap/octomap/issues/283, https://github.com/OctoMap/octomap/issues/287)

@xinyiz xinyiz force-pushed the fix-deleteNodeRecurs branch from 4a2e019 to c84c455 Compare March 23, 2020 18:45
@spurnvoj
Copy link

Hi, this seems straightforward :) Is something missing to do merge?

@ahornung
Copy link
Member

Yes, sorry for the delay. I wanted to check and add a few unit test beforehand, but that should happen soon.

@Levi-Armstrong
Copy link

We are also running into this assert. Friendly ping :)

@Levi-Armstrong
Copy link

@ahornung, Friendly ping :)

@@ -705,9 +705,13 @@ namespace octomap {
// TODO delete check depth, what happens to inner nodes with children?
this->deleteNodeChild(node, pos);

if (!nodeHasChildren(node))
if (!nodeHasChildren(node)){

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason not to do this cleanup in deleteNodeChild() already?
It semantically belongs to the deletion of the (last) child, and doing it outside may lead to having to add the same routine to other contexts from where deleteNodeChild is called.

Copy link
Member

@ahornung ahornung Sep 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! The only reason I can think of is the (probably) less efficient call of "pruneNode(...)", which does the cleanup once after deleting all 8 child nodes (instead of checking for every single call of deleteNodeChild if it's empty already).

Copy link

@christofschroeter christofschroeter Sep 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, when you know you are deleting multiple children, you may not want to check after each deletion (which means iterating the 8 child pointers).

So I would suggest adding a parameter to deleteNodeChild() whether to cleanup, which in my opinion should have a default of true.
And if the cleanup is done internally, it might be an idea to return the result of the internal nodeHasChildren() from deleteNodeChild(), saving an extra query as in deleteNodeRecurs()

@vikgus1
Copy link

vikgus1 commented Aug 22, 2023

Friendly bump =)

@jasonir129
Copy link

bump! same issue :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants