VASSAL 3.1.2 (generic version, oops now called linux version I guess)
Fedora 10 (Cambridge) kernel is 2.6.27.18-170.2.35.fc10.x86_64
latest Java (I believe OpenJDK) etc.
Gnome 2.24.3
everything that actually has an arch is 64-bit (x86_64) versions
machine is i7 920 2.67 GHz (8-core) with 6 GB RAM (reports as 5.8 GiB in System Monitor)
It used to work, this version even. But it has been since the 20th or 22nd of March that I last tried.
On starting the module manager appears, but it does not respond to any mouse commands, including the menu. So I can not even shut it down. In fact, even the window control box (whatever you call that in Fedora, the min/max/close thing in the top-right) while it will at least seem to respond to a click (unlike the menu) will not actually do anything. And the window will not repaint itself either if I bring something else over top. I can however drag the window around still, but can’t do anything else with it including close it or get it to re-paint.
error log in my VASSAL folder says only…
1238035885776 83494116 – Starting
1238035885776 83494116 – OS Linux
1238035885776 83494116 – Java version 1.6.0_0
1238035885776 83494116 – VASSAL version 3.1.2
1238035885782 83494116 – Manager
during hang System Monitor entries (CPU, RAM) do not seem too bizarre except Java is at only 62 MB and is sleeping in “futex_wait” for a waiting channel. VASSAL.sh is sleeping in “do_wait” for a waiting channel. This continues even after attempting to close the window.
System shutdown and restart and still hangs.
I have 3.1.0 still on the machine I can change to use that in need (hopefully does not have the same problem - but I do not think I have put a lot of hours in on any of the 3.1 non-beta releases yet).
no rush, when you think of something to try let me know.
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151
This is a Fedora 10 machine, just like mine. I’ve been using OpenJDK for
months with no problems. I doubt this is a problem with OpenJDK, so long
as it’s the current package.
I would recommend making sure that all of your packages are current first.
After typing ‘suspend’ and hitting enter, it should say “All threads
suspended.”. After typing ‘where all’, you should get a stack trace for
each thread. Please copy this output and post it here. This will tell
us where VASSAL is getting hung up.
You can stop the debugger by typing ‘quit’, and kill VASSAL now.
This is current. Did you check that all of your other packages are current?
(‘yum update’ if you’re root. ‘sudo yum update’ is better, though, if you’ve
set up sudo. That way you don’t have to become root.)
Had the MM already stopped responding when you did this? How long had it
been running?
Everything should be current as I update and check almost every day - except when the Fedora folks, or more likely their upstream contributors, mess something up on the networking or package management side or put up a package with dependency issues (only twice since November for me). In fact I would not be surprised if that occasionally bit me as sometimes things get pushed that are not quite ready for prime time after all.
Yes it never even seems to START responding… ‘hangs’ as soon as it starts.
I believe it had been running only long enough for me to verify it was hung, to open a new terminal, and to type the commands, say 15 or 20 seconds?
If you’re current, then you have the same packages as I have.
Try waiting a bit longer, say, 5 minutes, before suspending the threads
and dumping their stacks, and post that for me. I want to see if there’s
any difference.
Okay, again launched VASSAL from the terminal as follows…
[john-murphy@localhost ~]$ ls
Desktop Music Templates VASSAL-3.1.2 Videos
Documents Pictures VASSAL VASSAL.games workspace
Download Public VASSAL-3.1.0 VASSAL.modules
[john-murphy@localhost ~]$ cd VASSAL-3.1.2
[john-murphy@localhost VASSAL-3.1.2]$ ls
doc lib VASSAL.bat VASSAL.sh
[john-murphy@localhost VASSAL-3.1.2]$ java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n -classpath lib/Vengine.jar VASSAL.launch.ModuleManager
Listening for transport dt_socket at address: 8000
I then attached the debugger right away but then waited between 5 and 6 minutes (and checked it was still having issues - I could tell because the entire module manager screen was blank from not being re-painted) before suspending. Here is the dump…
[code][john-murphy@localhost ~]$ jdb -attach 8000
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb …
I have 27 system updates pending, but they just came “down the pipe” today and are since this problem started. I am waiting to do them so it does not impact troubleshooting this.
Two of them are security updates pertinent to this investigation… one to OpenJDK…
The method openXIMNative at the top of the event queue thread is the one
which is hanging. (I wanted to verify that the event queue stack trace
was the same no matter how long you waited.)
Java calls a function in libX11, and there’s a problem with libX11-1.1.5-1.
It appears to affect only 32-bit systems. (As evidence, I’m using that
version of libX11 on a 64-bit system, and it works fine for me.)
There’s already an update which has been pushed out, libX11-1.1.5-2, so the
next time you do a ‘yum update’ you should pick it up. (Sanity check: do
an ‘rpm -q libX11’ to check that you don’t already have libX11-1.1.5-2. If
you do already have libX11-1.1.5-2, then the problem is not really fixed
and we should reopen this bug.)
Further down the comments some people say that it does affect some 64-bit
systems. I hadn’t read to the bottom when I typed that.
The update was pushed today, so most likely it hasn’t made it to the mirror
you’re using yet. If you don’t want to wait for it, you can get the RPM
here
the last I remember doing before this started happening was I tried to open the La Bataille de France 1940 extension for A Las Barricades! as a module instead of an extension. Could not believe it did not open so I did it twice in fact and got the error dialog both times.
Just as a lark try doing that twice then restart your system and see if VASSAL hangs.
Otherwise if this looks untraceable any further I think I will go ahead and apply the new openjdk update mentioned a few posts back.
okay I see there is also a new bug 492018, which looks destined to be flagged as a duplicate, where the first comment is that it affects 64 bit systems also.
I think the best approach here is to go ahead and update and resolve this as a X11-java problem and certainly not a VASSAL one.
This is not to discourage you from keeping your system up-to-date, but
installing the newet OpenJDK package won’t make any difference. The problem
is with libX11.
Well you pegged that one. Changing from -11 to -13 or whatever it was per the security update for openjdk makes no difference.
I can wait for the X11 update to show up wherever it is my repos are pointed.
Of course this all means switching back to VASSAL 3.1.0 would have made no difference either. Luckily my online opponent for Clash of Monarchs “Old Fritz” regularly falls asleep at the Schnapps on me so he should mind waiting a couple days, if I even see his move by then!
But it would be kind of nice to be able to play some more with my module editor soon so hopefully it will not take too long.
EDIT - I finally got my repo mirror to show the update and indeed I can confirm that the update to X11 fixes this problem. Many thanks yet once again Joel.