[Mesa-dev] [Bug 111288] Memory leak in minecraft (supposedly related to rendering)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=111288

--- Comment #6 from Denis <denys.kostin at globallogic.com> ---
Thanks for the trace and explanations. I installed minecraft (demo version).
First observation - is that the app versions available for me 1.14.4 and 1.14

I ran it thru the valgrind. Result below:

==9226== LEAK SUMMARY:
==9226==    definitely lost: 672 bytes in 6 blocks
==9226==    indirectly lost: 9,878,823 bytes in 1,984 blocks
==9226==      possibly lost: 6,480,869 bytes in 26,861 blocks
==9226==    still reachable: 7,899,321 bytes in 62,276 blocks
==9226==                       of which reachable via heuristic:
==9226==                         length64           : 1,384 bytes in 28 blocks
==9226==                         newarray           : 1,808 bytes in 33 blocks
==9226==                         multipleinheritance: 1,960 bytes in 10 blocks
==9226==         suppressed: 0 bytes in 0 blocks


According to it, during my game session there were lost about 10 MB of memory.

I made tests on:
Manjaro OS
kernel 5.1.16-1-MANJARO
mesa 19.1.2 (system)
gpu - Intel HD620

Also I am not sure how memory allocation should work during app launching (I
mean, possibly that could be find that app requested memory in renderD128 and
freed it only after app closing...). It would be useful for me to know, why did
you decide that those records relate to memory leaks (my observation - after
normal game launching there were about 30 records for "renderD128" were
created. And they were not increased then)

upd - as I found out, these memleaks are for the Launcher, not the exact game.
Trying to connect to java process with valgrind now

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190807/3630848c/attachment.html>