Hi,

On 15.09.2016 11:00, Itai wrote:
What I should have said is I have never written anything in Mesa. I
tried making a small C program reproducing the problem, but I couldn't
get the same result (Not entirely sure what the JRE is doing).
I have run valgrind on the sample Java program, which produces a lot of
extraneous data, but I hope there is enough there to find the problem.


On a quick look I would say that the Java program / VM doesn't at exit get properly rid of the context(s) it creates. Additionally, I think it's creating compatibility profile, because largest allocations are from swrast context creation (AFAIK added for compat fallbacks).



At the time the program was stopped, it's memory consumption exceeded
1.5GB, only about 200MB of them accounted for by the JVM (which means
about 1.3GB were in native/mesa code).

I would recommend killing the process with a signal that Valgrind can catch, but program doesn't (e.g. SIGCPU is something most programs don't catch :-)). That way you see the actual run-time leaks instead of being confused with issues program creates with its exit code. A lot of programs don't properly free their resources at exit and people often confuse Valgrind reports of these application's exit issues with run-time leakage.


        - Eero

This was run using Mesa 12.0.2-1 on Debian testing. Attached is the
GZipped valgrind output, with hope it could help to find the problem, or
at least write a proper (non-Java) test case

On Thu, Aug 18, 2016 at 6:08 AM, Michel Dänzer <mic...@daenzer.net
<mailto:mic...@daenzer.net>> wrote:

    On 18/08/16 05:39 AM, Itai wrote:
    > (Posted initially in mesa-users, but got no reply - the list seems dead.
    > Couldn't find any bug report, and sadly not well versed enough in mesa
    > to file one myself).

    FWIW, there's no need to be versed in Mesa to file a bug report. :)


    > Following an investigation of a memory leak with JavaFX on some Linux
    > configuration, it looks like there is a possible memory leak when using
    > `glxMakeCurrent`.
    > Sadly, I myself don't know enough about OpenGL/Mesa to describe it
    > fully, but I'm hoping someone here can understand it well enough to make
    > a proper bug report.
    >
    > Here is a link to the discussion on the openjfx-dex list:
    > http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-August/019577.html
    <http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-August/019577.html>
    >
    > Here is a forum post describing a non-Java way to reproduce this same
    > issue:
    > http://www.gamedev.net/topic/679705-glxmakecurrent-slowly-leaks-memory/
    <http://www.gamedev.net/topic/679705-glxmakecurrent-slowly-leaks-memory/>
    >
    >
    > This was possibly not an issue in older versions of Mesa, as the bug
    > does not appear on older Linux installations (I'm using Mesa 11.2.2,
    > where the bug is present)

    Does it still happen with current Git master? There have been some fixes
    in this area recently.

    If it still happens, the output of running an affected application in
    valgrind --leak-check=full (with debugging symbols available for at
    least all Mesa binaries) would be useful.


    --
    Earthling Michel Dänzer               |               http://www.amd.com
    Libre software enthusiast             |             Mesa and X developer

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to