#3186 FreeCol freezes after changing availability of nations
In both FreeCol 0.11.6 and latest git HEAD, FreeCol freezes on the Players Table that comes up while creating a new game if you try to set a nation to "Not Available" or "None" (or even click on it and leave it at "Available"). Some parts of the GUI are still responsive. For example, if you do it right away, you can quit the client. But it is impossible to start the game and many UI elements simply cease functioning.
I haven't had the time to "git bisect" this and see when it first occured, but my impression is that this is relatively new behavior.
A partial workaround for this is to use the "-e" command line option that changes the default of some European nations to "Not Available". Using this allows you to start a game with fewer players without clicking on the availability drop down. This works fine.
However, if you click on the drop down, the bug still occurs.
Also, this only allows you to limit the number of European players, not to select specific ones. It also doesn't help if you want to limit the number of Native nations.
I am using OpenJDK 1.8.0_242 (64-bit) in Debian Linux (stretch). If I get a chance I'll do some additional testing and see if I can nail down a git commit where this issue first appeared.
I checked out 0.11.5 from git and rebuilt it with "ant clean && ant" and I still get the same behavior.
Last edit: Robert Mathias Marmorstein 2020-04-22
However commit a62e021e0eff1f0fb9037a71e62f294cd9033b95 works as expected.
Last edit: Robert Mathias Marmorstein 2020-04-22
There seem to possibly be two related issues. In some commits, clicking on the dropdown to select "Not Available" creates a graphics artifact where the dropdown menu does not close after selecting an option. However, when this happens it is still possible to start a game by clicking "Start Game" twice.
However in others, the delayed closing of the dropdown coincides with some sort of race condition or infinite loop that prevents the game from starting at all.
git bisect identifies commit: 0c4a7d05511c15017421216e72340ec9621cd72a
as the culprit for the "not being able to start the game" part of this bug. Testing confirms that the previous commit works (well, you still have to click "Start Game" twice) while that one doesn't.
The commit seems to reorder statements in the exception handling for "ReceivingThread" in the network code. That seems fairly removed from the particular symptoms I'm seeing, so I suspect that this change is only indirectly responsible for the breakage. I wish I understood the relationship between them better.
The other issue, the interface glitch seems to step from commit 16ed8d1f0e8b4765d93777f6a0aeed598023e2ff (Mass Message Renaming).
It looks like that commit (16ed8d...) added "extend JLabel" to the AvailableCellRenderer class. Making them JLabels led to the behavior that they don't disappear when something is selected.
Hmm. The problems seems to be in the following line of PlayerTable.java (line 196:
If I remove the call to nationState.getShortDescriptionKey() (for example, by replacing it with "Hello World") everything works fine. But if I put it back in, the game freeses when changing the availability of a plery.
With such a problem it is best to read the freecol.log file and attach some from your testing. It gets overwritten on each game run, so do not forget to copy it. That is probably something specific to your system.
I've duplicated this on several different Linux systems (at work and home). My freecol.log file doesn't seem to show anything relevant. :-(
I take that back. I was looking at the wrong file. There's actually a very useful NPE in my log file:
Last edit: Robert Mathias Marmorstein 2020-04-23
Checking whether value is null seems to fix the issue. Here is a patch.
Last edit: Robert Mathias Marmorstein 2020-04-23
Oh. You may not be able to apply that without also applying this, which fixes a different issue with the tooltip:
I have applied your patches (git..0826474), which hopefully fixes the problem for you.
There is unfinished business here, in that I was never able to reproduce the problem. So the question remains as to why you were seeing value==null. Nevertheless, I am confident your fix is right, so setting this report to Pending.
Thanks, Mike and Sebastien!
I do most of my teaching in C++ and Python these days, so I'm not as comfortable debugging Java code. I tried pulling this into NetBeans to see if I could get a good trace, but I'm afraid I'm just not comfortable enough in the interface to be able to figure out how to determine why the pointer is null.
I tried putting an assert in, but it didn't behave the way I expected. I'm happy to take any advice that might help narrow this down. We're about a week away from final exams, so I'm going to be pretty busy for the next two weeks, but after that I should have plenty of time to help out!
No worries. This is a volunteer project so we do not do deadlines, and Java is much more forgiving than C++ so do not let unfamiliarity dissuade you from making more excellent bug reports:-).
I suspect the null value problem is happening deep in the Swing libraries. If so, we are at a point of diminishing returns on the issue. OTOH, I am on the identical version of OpenJDK (albeit on Fedora) so it may be premature to blame Swing.