PlayN 2.0 released

[Michael Bayne]

To whom it may concern,

The stars have finally aligned to enable a PlayN 2.0 release. In fact, celestial cooperation was not necessary, but the MobiDevelop version of RoboVM with my Maven fixes was finally shipped to Maven Central, so I was finally able to ship a version of PlayN that builds out of the box for iOS again.

If you've been tracking the -rcN releases over the last two years, then there's nothing to get excited about here, other than being able to replace 2.0-rc4 with 2.0.

Just for fun, I generated API diffs between 1.9 and 2.0:

http://playn.io/docs/api/core/changes.html

http://threerings.github.io/tripleplay/apidocs/changes.html

While I had this dusty old box open, I also updated the LWJGL dependencies to 3.1.2 which meant switching to LWJGL's new "factored" backends. We only depend on the OpenGL and GLFW backends and their respective native libraries. If you were making use of some of the other stuff that was bundled into the "one giant shared library" 3.0 release, you may have to add some dependencies to yourgame/java/pom.xml.

PlayN remains in maintenance mode. I recently updated one of my little side projects a few months back, so I know it's still possible to ship a mobile game with it:

https://itunes.apple.com/us/app/pokeros/id794672036?ls=1&mt=8

https://play.google.com/store/apps/details?id=com.samskivert.mashups.pokeros

But I'm still on hiatus from in the game making business, so I have no plans to be adding to the platform.

A little birdie told me someone was working on a port of PlayN to Kotlin, but I won't spill any (more) beans here. I'm sure the guilty party will report to this mailing list if and when he feels like he wants more eyeballs on his project.

That is all. Thanks for keeping the faith,

Michael

-- m...@samskivert.com

[Andres Martinez Quijano]

Great news!

[Andrey Kleshchenko]

Great!

[Andres Q]

After updating (from 2.0-rc3 to 2.0) I noticed that I consistently get a crash of the JVM (it's not deterministically reproducible but it's consistent), I'm guessing it has to do with the updated LWJGL version:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fb2b4527e2c, pid=13087, tid=0x00007fb2f0bfb700
#
# JRE version: OpenJDK Runtime Environment (8.0_131-b11) (build 1.8.0_131-8u131-b11-2-b11)
# Java VM: OpenJDK 64-Bit Server VM (25.131-b11 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [liblwjgl_opengl.so+0x4ce2c]  Java_org_lwjgl_opengl_GL11_nglDeleteTextures__IJ+0xc

Reverting to 2.0-rc3 fixes it

[Michael Bayne]

On Tue, Jun 6, 2017 at 9:29 AM, Andres Q <tuls...@gmail.com> wrote:

After updating (from 2.0-rc3 to 2.0) I noticed that I consistently get a crash of the JVM (it's not deterministically reproducible but it's consistent), I'm guessing it has to do with the updated LWJGL version:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fb2b4527e2c, pid=13087, tid=0x00007fb2f0bfb700
#
# JRE version: OpenJDK Runtime Environment (8.0_131-b11) (build 1.8.0_131-8u131-b11-2-b11)
# Java VM: OpenJDK 64-Bit Server VM (25.131-b11 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [liblwjgl_opengl.so+0x4ce2c]  Java_org_lwjgl_opengl_GL11_nglDeleteTextures__IJ+0xc

Reverting to 2.0-rc3 fixes it

I saw that too. Alas.

You may not have to be quite as drastic as reverting to -rc3, you can change the LWJGL version in yourgame/pom.xml like so:

  <properties>
    <lwjgl.version>3.1.2</lwjgl.version>
  </properties>

If you want to revert to pre-3.1 (when they refactored all their jars) then you have to use -rc3, but maybe 3.1.1 or 3.1.0 don't have these crashes, so you could try those.

-- m...@samskivert.com

[Andres Martinez Quijano]

2017-06-06 13:35 GMT-03:00 Michael Bayne <m...@samskivert.com>:
> I saw that too. Alas.
>
> You may not have to be quite as drastic as reverting to -rc3, you can change
> the LWJGL version in yourgame/pom.xml like so:
>
> <properties>
> <lwjgl.version>3.1.2</lwjgl.version>
> </properties>
>
> If you want to revert to pre-3.1 (when they refactored all their jars) then
> you have to use -rc3, but maybe 3.1.1 or 3.1.0 don't have these crashes, so
> you could try those.

Ooooh, good to know... I'll try that. Thanks!

[Michael Bayne]

On Tue, Jun 6, 2017 at 9:35 AM, Michael Bayne <m...@samskivert.com> wrote:

I saw that too. Alas.

Also I'll try poking at this a bit myself. Maybe PlayN is doing something dumb that old LWJGL coped with but now it freaks out.

In my crash traces I saw something about the finalizer thread, so maybe we're trying to delete textures on the finalizer thread... Though I'm pretty sure we do not do that. I remember writing code to queue up textures to be deleted on the main thread if we determine in a finalizer that a texture needs to be freed.

-- m...@samskivert.com

[Andres Martinez Quijano]

2017-06-06 13:40 GMT-03:00 Michael Bayne <m...@samskivert.com>:
> Also I'll try poking at this a bit myself. Maybe PlayN is doing something
> dumb that old LWJGL coped with but now it freaks out.
>
> In my crash traces I saw something about the finalizer thread, so maybe
> we're trying to delete textures on the finalizer thread... Though I'm pretty
> sure we do not do that. I remember writing code to queue up textures to be
> deleted on the main thread if we determine in a finalizer that a texture
> needs to be freed.

In my case it happened when I ran this code (but not the first time,
and not always at the same time)

screens.replace(new LevelScreen(this, plat, new Level1()));

in a standard SceneGame class, maybe the cleanup of the popped screen
is causing trouble?

[Brigt Vik]

My game crashes almost immediately using LWJGL 3.1.2, 3.1.1, 3.1.0 and 3.0.0, using PlayN 2.1-SNAPSHOT. The stacktrace in the core dump indicates that indeed deleteTextures is used as part of finalize in ImageLayer. Hope that helps!

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.lwjgl.opengl.GL11.nglDeleteTextures(IJ)V+0
j  org.lwjgl.opengl.GL11.glDeleteTextures(Ljava/nio/IntBuffer;)V+8
j  playn.java.LWJGLGL20.glDeleteTextures(ILjava/nio/IntBuffer;)V+1
j  playn.core.GL20.glDeleteTexture(I)V+17
j  playn.core.Texture.close()V+23
j  playn.core.Texture.release()V+48
j  playn.scene.ImageLayer.setTile(Lplayn/core/Tile;)Lplayn/scene/ImageLayer;+22
j  playn.scene.ImageLayer.finalize()V+5
J 900 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x000000000322b474 [0x000000000322aee0+0x594]
J 899 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00000000032225b4 [0x0000000003222540+0x74]
j  java.lang.ref.Finalizer$FinalizerThread.run()V+45
v  ~StubRoutines::call_stub

[Brigt Vik]

Disregard the bit about me trying various versions of LWJGL, I realized I was stupidly changing that setting in my game pom, not the PlayN pom. So it was still using 3.1.2 every time. The stacktrace is still valid though.

[Michael Bayne]

On Sat, Jun 10, 2017 at 12:33 AM, Brigt Vik <bov...@gmail.com> wrote:

The stacktrace in the core dump indicates that indeed deleteTextures is used as part of finalize in ImageLayer. Hope that helps!

Yeah, looks like I just didn't account for that case. One is never too old to make dumb mistakes. :)

I pushed a fix that fixes that and avoids the potential for this sort of problem in the future. Once we confirm that the crash seems to go away, I'll ship a 2.0.1 release.

-- m...@samskivert.com

[Brigt Vik]

Works for me! My game now has run for 3 minutes without a crash, while it would consistently crash within 5 seconds prior to this update.