-
Notifications
You must be signed in to change notification settings - Fork 23
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
Memory issue fix #57
Open
jianguan210
wants to merge
2
commits into
NanoComp:master
Choose a base branch
from
jianguan210:memory_issue
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Memory issue fix #57
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't make sense to me.
t->objects
is an array of pointers to objects, but it doesn't "own" the objects and is not responsible for freeing them. (Even if it were, this code is only freeing the first object in the list, and only for prisms?)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback. If I understand correctly, the purpose of this function is to destroy (free) all the memory associated with a
geom_box_tree_struct
object. Since we do not have the C++ style destruction function, we need to manually free all the arrays from bottom to top. The chain I found is:geom_box_object
-->geometric_object
-->prism_struct
-->vectors3_list
-->items
. If we only free the top level object, the lower level memory allocated by pointers will be leaked (since no pointers are cleaned, and not pointing to the heap arrays).I think only
prism
structure has this issue, other geometry objects do not have because they do not have heap arrays allocated by pointers.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
geom_box_tree
object is used in situations like this or this or this where it is an auxiliary data structure to a lineargeometric_object_list
— the objects should only be freed when the corresponding list is destroyed (which should happen after the tree is destroyed). (Moreover, the same object may appear in multiple branches of the tree, so you have to be careful not to free it multiple times.)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation. Since free of NULL pointer is safe, that is why NULL is assigned to the pointers after memory is freed to avoid double deletion.
There are no such memory leak issue in simulation (forward and adjoint) flow. It only happens in
calculate_gradient
. The flow is:calculate_gradient
->get_gradient
->destroy_geom_box_tree
in "meep-python.cxx".Also could you please point me to the place we destruct
geometric_object_list
since I did not find it? Thanks.