Memory leak
See original GitHub issue- I have read the guidelines for submitting issues
🐛 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
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
Issue Analytics
- State:
- Created a year ago
- Reactions:8
- Comments:5
Top Results From Across the Web
Memory leak - Wikipedia
In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations in...
Read more >What is Memory Leak? How can we avoid? - GeeksforGeeks
Memory leak occurs when programmers create a memory in heap and forget to delete it. The consequences of memory leak is that it...
Read more >Definition of memory leak - PCMag
When memory is allocated, but not deallocated, a memory leak occurs (the memory has leaked out of the computer). If too many memory...
Read more >Memory leak - OWASP Foundation
A memory leak is an unintentional form of memory consumption whereby the developer fails to free an allocated block of memory when no...
Read more >Find a memory leak - Windows drivers - Microsoft Learn
A memory leak occurs when a process allocates memory from the paged or nonpaged pools, but doesn't free the memory.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Fixed in 0.40.2. Thank you!
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
GC root seems to be Gradle listenerManager:
And here a different one: