P2
For some an unknown reason, this has been only reproducible on Mac.
But I don't see a technical reason, why this shouldn't happen also on Windows are Linux.
To reproduce this bug, in a minimal setup, we have to make sure of the following:
- maximum available ram should be minimal, to quicker reproduce this issue. Setting it to 100MB with -Xmx100m worked for me.
- Stimulating the GC is helpful - especially to make sure the timing of the GC is random instead of when the application allocates something. The timing of the GC is important, otherwise the textures get disposed from the JavaFX thread.
- We have to create enough textures from the JavaFX Thread.
- The printing thread has to depose one of these textures. This is sometimes triggered during printing textures.
(In the affected application, this crash is triggered about every 3rd print with javafx)
files:
- hs_err file
- test image
- reproducing test program
But I don't see a technical reason, why this shouldn't happen also on Windows are Linux.
To reproduce this bug, in a minimal setup, we have to make sure of the following:
- maximum available ram should be minimal, to quicker reproduce this issue. Setting it to 100MB with -Xmx100m worked for me.
- Stimulating the GC is helpful - especially to make sure the timing of the GC is random instead of when the application allocates something. The timing of the GC is important, otherwise the textures get disposed from the JavaFX thread.
- We have to create enough textures from the JavaFX Thread.
- The printing thread has to depose one of these textures. This is sometimes triggered during printing textures.
(In the affected application, this crash is triggered about every 3rd print with javafx)
files:
- hs_err file
- test image
- reproducing test program
