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

Memory leak #536

Closed
1 task done
yacine-ser opened this issue Apr 14, 2022 · 5 comments · Fixed by #546
Closed
1 task done

Memory leak #536

yacine-ser opened this issue Apr 14, 2022 · 5 comments · Fixed by #546
Assignees

Comments

@yacine-ser
Copy link

yacine-ser commented Apr 14, 2022

🐛 Describe the bug

When using the version 0.40.1, our builds fail with the following error

an FAILURE: Build failed with an exception.
* What went wrong:
GC overhead limit exceeded

After adding +HeapDumpOnOutOfMemoryError to the jvmargs and analysing the hprof we got the following report from Eclipse MAT

Screenshot 2022-04-13 at 16 44 10

Note :
Current jvmargs in our gradle.properties
org.gradle.jvmargs=-Xmx4096m -XX:+HeapDumpOnOutOfMemoryError

⚠️ Current behavior

After multiple builds we have to restart the gradle deamon because it is taking most of the allowed allocated memory.
Not stopping it result in very slow builds and the above mentioned error.

✅ Expected behavior

That our build time remains consistent

💣 Steps to reproduce

N/A

📱 Tech info

N/A

@yacine-ser
Copy link
Author

yacine-ser commented Apr 19, 2022

Additional info :
The version 0.40.0 is not affected by this issue.
It seems to be a side effect of this change

@LouisCAD
Copy link
Member

Hello, thank you for the report, I was suspecting that we had a memory leak issue but had failed to find where to look exactly.

I'll try to pinpoint where it's rooted, starting from the information you provided, and I hope we can find a solution for the next release.

@soywiz-invideo
Copy link

soywiz-invideo commented Apr 21, 2022

Quick update:
We found that another gradle plugin was the one that caused most the huge leak, though it was not obvious. It looked that refreshVersions had some leaked instances (added instances between each ./gradlew call), but those aren't retaining too much memory and is really minor at least in 0.40.0 👍

And indeed confirmed that after bumping to 0.40.1 there is a huge leak with gradle. Pretty huge because we have lots of modules and dependencies, so maybe it is more noticeable than normal.

We are using refreshVersions 0.40.0, and we have a pretty big leak just running ./gradlew, diffing two gradle heaps we found this (in the case it is helpful):

Click to expand Screenshot 2022-04-21 at 18 25 34

GC root seems to be Gradle listenerManager:

Screenshot 2022-04-21 at 19 13 25 Screenshot 2022-04-21 at 19 14 40

And here a different one:

Screenshot 2022-04-21 at 19 35 42

@LouisCAD LouisCAD self-assigned this May 3, 2022
@LouisCAD
Copy link
Member

LouisCAD commented May 29, 2022

I now have a reproducer in CI (see #546) and I'll be working on fixing this this week.

Thank you a lot for the help in pinpointing this.
It's related to code inside UsedPluginsHolder and triggers when refreshVersions manages the version of another Gradle plugin.

@LouisCAD
Copy link
Member

Fixed in 0.40.2.
Thank you!

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 a pull request may close this issue.

3 participants