Possible leak on prism es2

[Thiago Milczarek Sayão]

Hi,

Pardon me If I'm bothering with nonsense, but I really think there's a
leak, mainly because DrawableInfo is never freed (I did not find any code
that frees it).

Using valgrind, I see *many* entries like this:

==28403== 1,464 bytes in 61 blocks are still reachable in loss record
15,444 of 16,301
==28403==    at 0x4846828: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==28403==    by 0x2BF83E5C:
Java_com_sun_prism_es2_X11GLDrawable_nCreateDrawable (in
/home/tsayao/IdeaProjects/jfx/build/sdk/lib/libprism_es2.so)
==28403==    by 0x15E9FB3B: ???
==28403==    by 0x15E9B2D5: ???
==28403==    by 0x15E9B1DF: ???
==28403==    by 0x15E9B379: ???
==28403==    by 0xED02F83: ???
==28403==    by 0xED267B3: ???
==28403==    by 0x15E9B1DF: ???
==28403==    by 0x15E9B6E5: ???
==28403==    by 0x15E9B6E5: ???
==28403==    by 0x15E9B1DF: ???



Valgrind command:
valgrind --leak-check=full --track-origins=yes --show-leak-kinds=all
--suppressions=java.supp  --log-file=valgrind.log java
@/home/tsayao/IdeaProjects/jfx/build/run.args TestScenes.java

Suppression file (java.supp):
{
   # Suppress Java's native code memory allocations
   Memcheck:Leak
   obj:/usr/lib/jvm/jdk-22-oracle-x64/lib/server/libjvm.so
   fun:malloc
   fun:calloc
   fun:realloc
   fun:free
}

TestScenes.java:
public class TestScenes extends Application {

    @Override
    public void start(Stage stage) {
        // Create a timeline animation to switch between scenes
        Timeline timeline = new Timeline(
                new KeyFrame(Duration.millis(100), e ->
stage.setScene(createScene("Scene 1", Color.RED))),
                new KeyFrame(Duration.millis(200), e ->
stage.setScene(createScene("Scene 2", Color.BLUE))),
                new KeyFrame(Duration.millis(300), e ->
stage.setScene(createScene("Scene 3", Color.GREEN)))
        );

        timeline.setCycleCount(Animation.INDEFINITE);
        timeline.play();

        stage.show();
    }

    private Scene createScene(String text, Color color) {
        return new Scene(new StackPane(), 400, 300, color);
    }

    public static void main(String[] args) {
        launch(TestScenes.class, args);
    }
}




Em qui., 26 de set. de 2024 às 08:14, Thiago Milczarek Sayão <
thiago.sayao at gmail.com> escreveu:

> Hi,
>
> I'm investigating the code, and for someone not familiar with it, it's
> very complex.
>
> On com.sun.javafx.tk.quantum.WindowStage it will do this when changing
> scene:
>
> if (oldScene != null) {
>     ViewPainter painter = ((ViewScene)oldScene).getPainter();
>     QuantumRenderer.getInstance().disposePresentable(painter.presentable);   // latched on RT
> }
>
> But not when closing the Sage (possible problem #1).
>
> When changing scenes, ES2SwapChain dispose will be called:
>
> public void dispose() {
>     if (stableBackbuffer != null) {
>         stableBackbuffer.dispose();
>         stableBackbuffer = null;
>     }
> }
>
>
> But it does not dispose the  drawable that should clear the native struc
> DrawableInfo created, I think (possible problem #2).
>
> Does it make sense?
>
> -- Thiago.
>
>
>
> Em ter., 24 de set. de 2024 às 14:10, Thiago Milczarek Sayão <
> thiago.sayao at gmail.com> escreveu:
>
>> I might be mistaken, but it seems deleteDrawableInfo is never called.
>>
>> I think it should be called when the platform View is replaced or when
>> the window is closed.
>>
>> Github search for deleteDrawableInfo
>>
>> https://github.com/search?q=repo%3Aopenjdk%2Fjfx%20deleteDrawableInfo&type=code
>>
>> Em ter., 24 de set. de 2024 às 09:07, Thiago Milczarek Sayão <
>> thiago.sayao at gmail.com> escreveu:
>>
>>> Hi,
>>>
>>> While doing some work on replacing GLX with EGL I discovered a possible
>>> leak.
>>>
>>> Running this test:
>>> gradle -PFULL_TEST=true -PUSE_ROBOT=true  :systemTests:test --tests
>>> SetSceneScalingTest
>>>
>>> will result in X11GLDrawable -> nCreateDrawable to be called multiple
>>> times on the same test, while GLDrawable -> deleteDrawableInfo is never
>>> called, generating a leak (I think).
>>>
>>> I can probably fix this, but I still have little knowledge on the es2
>>> part, so any help would be appreciated.
>>>
>>> -- Thiago.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240927/2bdc22c4/attachment-0001.htm>