setFullScreenWindow Dies

Java 2D
#1

A player reports to me that one of my games dies after starting up, leaving an unresponsive black screen.

After giving him a version with extra logging, I determined that the problem occurs when the game calls setFullScreenWindow() in the (default) GraphicsDevice. It never returns from that call. Of course, it could be that he is getting impatient and killing the process before setFullScreenWindow() can generate an exception or even return without throwing an exception.

Now, it’s possible that this player has driver problems, etc. But how to debug this particular failure? Would turning on the assertions in the JVM provide more information? I didn’t try changing the trace level, yet, either. I plan to prepare a hotfix for him which would generate some additional information. I am just not sure how best to do that. I suppose that in the long run the best approach might be to compile a custom JVM? Well, I don’t have the knowledge to do that. Not this week, anyway. :wink:

Ideas?

#2

Hello

Please provide a SSCCE, indicate which version of Java you use, tell us whether you use the JRE installed on the operating system or the JRE embedded with your software, tell us in which context this problem occurs (operating system, architecture, GPU, driver version number if relevant), …

The exclusive fullscreen mode in the standard Java API doesn’t work on all supported platforms as far as I remember. For example, when I used it more than 10 years ago, it didn’t support several window managers under GNU Linux.

Maybe you’ll use another API to achieve the same goal on the long term.

#3

[quote]Please provide a SSCCE, indicate which version of Java you use…
[/quote]
Of course!

The game uses an embedded 32-bit JRE. The current version is AdoptOpenJDK 1.8.0_242. The same results were also obtained with Oracle’s 1.8.0_201.

The player is running Windows 10 Home 64-bit (10.0, Build 18362).

His machine is an MSI GT72S 6QE. He is not using a secondary monitor.

The display card is NVIDIA GeForce GTX 980M.

I have the DXDiag info from the player, if that helps: http://pastebin.java-gaming.org/7db6d717c5113

Here is a snippet of the relevant code section:

http://pastebin.java-gaming.org/db6d18c715316

The crucial portion is like this:

// Note: controller and gd are class variables.
    
…
GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();

controller.addGameLogEntry("Determine Device", true);

gd = ge.getDefaultScreenDevice();

controller.addGameLogEntry("Set Exclusive Screen Mode", true);

try {
    gd.setFullScreenWindow(this);
} catch (Exception e) {
	controller.addGameLogEntry(e, true);
}

controller.addGameLogEntry("Init Display Priorities", true);

The relevant portion of the log is showing this

Add listeners
Set Game Frame Params
Check Environment
Determine Device
Set Exclusive Screen Mode

Yes, I realize that the Java2D fullscreen mode doesn’t run well on other platforms, but I have had good success with it on Windows. But there is an occasional machine that has a problem and I don’t see how easily to debug this remotely. As I said, I am not 100% certain that the player isn’t giving up a little too quickly, but the game’s logic is not resuming after the call to setFullScreenWindow(). But the process isn’t crashing, either, apparently.

I mostly made my original post to ask about alternatives such as using assertions in the JVM, etc.

#4

It should work under Windows 10 with a single monitor.

Have you tried to call jstack on his machine?

#5

I haven’t tried jstack. I am not very familiar with it. It so happens that I don’t have physical access to the player’s machine. Unless I am mistaken, the player would have to run jstack from the command prompt and then report the results back to me? Is there another way to use this tool? Remote desktop access is probably out of the question.

#6

You can create a process in your game to run jstack when you detect a freeze but maybe it’s a lot easier for you to ask your end user to run jstack in command line.

#7

That is a good idea! I will integrate something like that into the game’s logic. I suppose that some other things are possible, such as giving the player a JRE with debugging included in the JDK’s build. Would that make the JVM’s assertions a useful option? I don’t know. I am only beginning to explore other ideas such as these.

In order to use jstack on the player’s machine, I will certainly have to update the embedded JRE that I include with the game. That’s worth thinking about for other people deploying games with an embedded JRE. Of course with modular Java there really isn’t a JRE versus a JDK anyway.

#8

Maybe AdoptOpenJDK builds already have debug symbols.