Test builds for 3.3.0

Probably a result of the build version having the -svnXXXX tag, but I tried to make a simple module to see if I could make the bare minimum that would fail, and the test build will not load modules created by itself. You can create a new module, but once you save and try to re-open the module, it won’t do it because the versions “don’t match” (it reports the same version string twice in the error).

Joel,
I am playing an OCS Tunisia II game with 3.3.0.
One general remark, as I noticed that with other modules I opened yesterday, is that the game menu icons and the game board itself are displayed at a much higher “zoom” (not sure it is the right term here) than 3.2.17.
So for the same zoom level in the game, the hexes and counters look bigger, but also you see more the individual pixels of the images.

You notice that straight away by looking at the hex lines that look more jagged in 3.3.0.

I do not know if that change in resolution from 3.2.17 is voluntary, but it seems to have negative an impact (in my opinion) on the look of the game. On the other hand, the Vassal control box (where all available modules are listed) is also bigger, and that is a good point.

Hope this helps,
Claudio

On the null reference error, I believe I’ve found an explanation. It happens when the max visible size of the Deck is less than the total number of cards in it, because the return value of StackMetrics.getContents is ignored, but it has not populated the entire positions array. This patch avoids the issue (but there may be a better fix, I do not know the project that well):

Index: src/VASSAL/build/module/map/StackMetrics.java
===================================================================
--- src/VASSAL/build/module/map/StackMetrics.java	(revision 9280)
+++ src/VASSAL/build/module/map/StackMetrics.java	(working copy)
@@ -320,7 +320,7 @@
     Rectangle region = visibleRect == null ? null : map.mapRectangle(visibleRect);
     Point[] positions = new Point[stack.getPieceCount()];
     Rectangle[] bounds = region == null ? null : new Rectangle[stack.getPieceCount()];
-    getContents(stack, positions, null, bounds, mapLocation.x, mapLocation.y);
+    int limit = getContents(stack, positions, null, bounds, mapLocation.x, mapLocation.y);
 
     for (PieceIterator e = new PieceIterator(stack.getPiecesIterator(),
                                              unselectedVisible);
@@ -327,6 +327,7 @@
          e.hasMoreElements();) {
       GamePiece next = e.nextPiece();
       int index = stack.indexOf(next);
+      if (index >= limit) continue;
       Point pt = map.componentCoordinates(positions[index]);
       if (bounds == null || isVisible(region, bounds[index])) {
         if (stack.isExpanded() || !e.hasMoreElements()) {

Those of you who had the NullPointerException, please try 3.3.0-svn9280 to see if it still occurs. (I made a one-line change to Map.java as cleanup, but accidentally changed how Decks are handled.)

I can’t replicate this. Can you post screenshots of both?

My original report was while using svn9280. Since your cleanup change was in rev 9258, I tried svn9251, but the same error occurred. I’ve attached a module for you that crashes, and one that doesn’t. The only difference is a third card added to the deck. That deck has its visible size limited to 2.

I haven’t been able to reproduce the problem on Linux. Does it still happen for you with svn9284?

9284 on macOS seems to have a problem with the embedded JRE and launching the Player from the module manager. Instead I tested by running the command line from the log (adding --standalone), and then by updating the shell script to run with the system JRE instead. Both methods showed no null reference failure for my Crash module, so that’s good news.

When launching the module from the manager, it reports a socket error with this trace:

java.util.concurrent.ExecutionException: java.io.IOException: Cannot run program "/Applications/VASSAL.app/Contents/MacOS/jre/bin/java": error=2, No such file or directory
	at java.base/java.util.concurrent.FutureTask.report(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.get(Unknown Source)
	at java.desktop/javax.swing.SwingWorker.get(Unknown Source)
	at VASSAL.launch.AbstractLaunchAction$LaunchTask.done(AbstractLaunchAction.java:604)
	at VASSAL.launch.Player$LaunchAction$1.done(Player.java:188)
	at java.desktop/javax.swing.SwingWorker$5.run(Unknown Source)
	at java.desktop/javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(Unknown Source)
	at java.desktop/sun.swing.AccumulativeRunnable.run(Unknown Source)
	at java.desktop/javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(Unknown Source)
	at java.desktop/javax.swing.Timer.fireActionPerformed(Unknown Source)
	at java.desktop/javax.swing.Timer$DoPostEvent.run(Unknown Source)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
	at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
	at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.io.IOException: Cannot run program "/Applications/VASSAL.app/Contents/MacOS/jre/bin/java": error=2, No such file or directory
	at java.base/java.lang.ProcessBuilder.start(Unknown Source)
	at java.base/java.lang.ProcessBuilder.start(Unknown Source)
	at VASSAL.tools.io.ProcessLauncher.launch(ProcessLauncher.java:111)
	at VASSAL.tools.io.ProcessLauncher.launch(ProcessLauncher.java:87)
	at VASSAL.tools.io.ProcessLauncher.launch(ProcessLauncher.java:65)
	at VASSAL.launch.AbstractLaunchAction$LaunchTask.doInBackground(AbstractLaunchAction.java:489)
	at VASSAL.launch.AbstractLaunchAction$LaunchTask.doInBackground(AbstractLaunchAction.java:244)
	at java.desktop/javax.swing.SwingWorker$1.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.desktop/javax.swing.SwingWorker.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: error=2, No such file or directory
	at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
	at java.base/java.lang.ProcessImpl.<init>(Unknown Source)
	at java.base/java.lang.ProcessImpl.start(Unknown Source)

The path to bin/java (as logged) does exist and is executable (after all, it runs the manager). I’m not entirely sure what this is about.

Thus spake Malnorma:

When launching the module from the manager, it reports a socket error
with this trace:

I cannot see a reason why this should happen—as you say, the Manager
would not start if that path did not exist or was not executable.

I’m not sure how to proceed from here.


J.

Possibly the embedding of the JRE will need to be reversed. It’s a shame, because not having to deal with dozens of different JRE versions would be better. Roll on, Vassal 4.

The problem is not specific to launching java to kick off the tiling. I set up a Catalina VM last night so I could try this myself. I found that replacing the call to java with a shell script fails in the same way, as does invoking /bin/bash directly. It seems like java.lang.ProcessBuilder isn’t seeing the filesystem.

It may be an auto-sandboxing thing. Is it able to launch /usr/bin/java? I had no problems when using that instead of the embedded JRE (providing java appears in the security and privacy exception list).

Thus spake Malnorma:

“uckelman” wrote:

The problem is not specific to launching java to kick off the tiling.
I set up a Catalina VM last night so I could try this myself. I found
that replacing the call to java with a shell script fails in the same
way, as does invoking /bin/bash directly. It seems like
java.lang.ProcessBuilder isn’t seeing the filesystem.

It may be an auto-sandboxing thing. Is it able to launch /usr/bin/java?

I don’t have a system Java installed on this VM.

Using the bundled Java, I get the same IOException with this trivial
program:

package VASSAL.test;

import java.lang.Process;
import java.lang.ProcessBuilder;

public class RunTest {
public static void main(String args) throws Exception {
final ProcessBuilder pb = new ProcessBuilder(“/bin/ls”);
pb.redirectOutput(ProcessBuilder.Redirect.INHERIT);
final Process proc = pb.start();
proc.waitFor();
}
}

This has no problem listing the contents of the working directory
on Linux.

I had no problems when using that instead of the embedded JRE
(providing java appears in the security and privacy exception list).

Is there anywhere one can check if you’re running into sandboxing?
Are denials logged? The error message is rubbish if that’s what’s
happening.


J.

If I run the Module Manager from the app bundle, VASSAL shows up as not sandboxed in the Activity Monitor.

I found something - under jre/lib there is an executable called jspawnhelper, but it does not have execute permissions. When I chmod +x that, the problem is resolved.

I just found that very thing about an hour ago. It’s used by ProcessBuilder to handle some issues with forking. Aggravatingly, jlink strips the execute bits off that file when it produces a java bundle.

Try svn9285.

Yep, all sorted now.

Hello Joel,
I figured out why 3.3.0 seems to display everything with a kind of zoom.
I have setup my windows display properties to have a zoom of 125. (You can set that by right clicking on the desktop background and selecting Display Parameters (well in French it is “Paramètres d’Affichage”. That opens a Win 10 parameter screen where above the Display Resolution you have a Dropdown titled “Modify the size of Text, Applications and other elements” where I had set it to 125 just after installing Win 10.

THis 125% setting seems to be ignored by 3.2.17 whereas it is taken into account by 3.3.0.

So in fact it is not an issue, but a new way to react to that parameter. For the “Manager window” (where all the modules are listed) it is nice that this happens, but if it could be controlled in the code of Vassal, it would be better that the Game Maps do not react to this Windows setting, as the bitmap of the game does not seem to be magnified well by this.

Kr
Claudio

Joel, I am now trying to play all my ongoing games with the latest build.
Yesterday I opened the log of a Vietnam game and got the following module errors.

  • VG Vietnam version 4.3.4
  • Loading Claudio_vs_Petri_Vietnam_01236.vlog …
  • Bad Data in Module: Illegal date format 7/6/19 8:15 PM
  • Bad Data in Module: Illegal date format 7/24/18 12:24 PM
  • Bad Data in Module: Illegal date format 6/28/18 10:28 PM
  • Bad Data in Module: Illegal date format 6/26/18 9:42 PM
  • Bad Data in Module: Illegal date format 6/26/18 8:47 PM
  • Bad Data in Module: Illegal date format 5/31/18 10:50 PM
  • Bad Data in Module: Illegal date format 5/29/18 10:35 PM
  • Bad Data in Module: Illegal date format 5/29/18 8:54 PM
  • Bad Data in Module: Illegal date format 5/28/18 9:41 PM
  • Bad Data in Module: Illegal date format 5/28/18 7:06 PM
  • Bad Data in Module: Illegal date format 5/7/18 10:07 PM
  • Bad Data in Module: Illegal date format 5/7/18 7:51 AM
  • Bad Data in Module: Illegal date format 5/5/18 11:05 PM
  • Bad Data in Module: Illegal date format 5/4/18 10:28 PM
  • Bad Data in Module: Illegal date format 5/6/18 8:16 AM
  • Bad Data in Module: Illegal date format 5/6/18 6:43 PM
  • Bad Data in Module: Illegal date format 5/29/18 8:50 PM
  • Bad Data in Module: Illegal date format 5/29/18 8:59 PM
  • Bad Data in Module: Illegal date format 7/24/18 9:31 AM
  • Bad Data in Module: Illegal date format 7/24/18 10:37 PM
  • Bad Data in Module: Illegal date format 10/29/18 7:14 PM
  • Bad Data in Module: Illegal date format 11/4/18 9:35 PM
  • Bad Data in Module: Illegal date format 7/7/19 10:55 PM
  • Bad Data in Module: Illegal date format 10/4/19 10:27 PM
  • Loaded Claudio_vs_Petri_Vietnam_01236.vlog

The same module loads without problem in 3.2.17
I saw in some games in 3.1.17 “Bad Data” errors that come up the 1st time you load a module so I delete the module from the list of recent modules. Tried to do that in 3.1.17 but it did not occur.
I am in France and the french date format is more like DD/MM/YYYY. But my adversary might use
I tried to see into the vlog with Notepadd++if I could find a date that matches in palin text.

I create a new game in 3.2.17. Moved some counters, saved the logfile, then reopened it in 9287
The error does not appear.

No more ideas about how to identify the cuase of this error.
If you give me some indications, I might run further tests. Or send you the files themselves.
Used 9287

Kr
Claudio

Thus spake ClaudioC:

Joel, I am now trying to play all my ongoing games with the latest
build.
Yesterday I opened the log of a Vietnam game and got the following
module errors.

We’ve changed nothing in our own code which parses dates. This is
probably due to a change in Java between versions 6 and 13. I’ll need
a vlog file which triggers the error in order to troubleshoot the
problem.


J.