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 leak in ETNode::setFather #1147
Comments
assigned to @isanbard |
I give on this one. I can't see the trees for the forest. Actually, its more a matter of time. It will take me many hours to get a clear For the next person to tackle this, here is what Danny Berlin (author of Reid Spencer wrote:
The new father should get linked into the occurrence splay tree, no? I'm assuming its the previous incarnation of "father" that
It is not, because the subtree is only going to be updated, not destroyed.
The ETOccurrences splay-tree stores the dfs sequence that you would get Thus, multiple etnodes may have the same etoccurrence as their father, This makes the lifetimes a bit hard for etoccurrences (etnodes are It is possible that what is happening here is that some part of the This is a random guess. We wouldn't leak ETNodes in this case because Can you help my understanding a little or point me
You can conceptually view them as completely separate trees except that Past that, it just so happens that etnodes know their parent and |
I have a fix for this. It uses ye olde reference counting on ETOccurrence nodes to delete them when they're |
you add an ivar? I have a patch in my email that may help with this, I'll forward it to you. |
Cool! I'll take a look at it. Thanks! |
refs llvm#1147 最適化成功メッセージへの情報追加 See merge request a64fx-swpl/llvm-project!16
Extended Description
run
valgrind --tool=memcheck -leak-check=full --num-callers=20 analyze -etforest
hsat.bc 2> leak_report
The text was updated successfully, but these errors were encountered: