Maptools lockup when chatting

[Hyperion wildfire]

I have recently been attempting to run maptools using Ubuntu (Linux) 14.04 with the gnome-fallback metacity desktop environment. I’m running on a 64bit machine with Oracle Java 6 and 7 installed and Oracle java 6 set to the default Java (I have fully removed openjdk to make sure that wasn’t the problem). I am running a bash shell specifically to run maptools though I typically run the machine in a C-shell or K-shell as I have much more experience with those. I am starting maptools with the Launch Maptools.sh script (both a modified and unmodified version of the script cause the same problem)

The interface runs perfectly when running it on just my own machine however, whenever I connect to a server it locks up if anyone else tries to enter something into the chatox. This happens when other people try to type but also when the initiative tracker ticks over but not when new people connect to the server or when I type in the chat box myself. When I close the chat display macros and other people chatting work fine but the initiative tracker alerts about someone new receiving initiative still cause the lockup. We are not running any frameworks, just a few of our own token macros.

At first I thought this might be a memory issue so I set the minimum and maximum memory in the Launch Maptools.sh to 1024m and the stack size to 5m. This is a brand new computer with 16GB of ram so it should easily be able to handle this. This did not fix the problem.
I then tried changing the JAVA_HOME variable in the script to specify exactly where I had installed Oracle Java 6 to ensure the correct version was being used. I encountered exactly the same problem. Finally I tried removing Java 7 altogether and running from both the modified and unmodified version of Launch Maptools.sh

I am now at a loss as to what else to try, I have tried searching both the forums and on google for a solution and have yet to find another mention of this problem. Unfortunately my new laptop did not come with a windows install and I no longer have the old one so simply reverting back isn't an option for me. Any suggestions are much appreciated.

[RPTroll]

Which version of MapTool are you using?

[Hyperion wildfire]

Yes sorry I forgot to include that. I'm using version 1.3.b84 which I believe is the latest stable release (it is the one which launches from the web launcher in any case). It's the same version the my GM and the other players are using. I was initially running it from the web launcher when I encountered the problems, I have since downloaded it and tried to fix the problem myself (as described in my initial post) without any luck. The specific Java version I'm using is 1.6.0_45 in case this is important.

Cheers
Hyperion

[RPTroll]

I hate to say this but I recommend everyone going ti b91. It has a large number of bug fixes from b94. Also, a stack size of 5mb is really large.

[Hyperion wildfire]

Thanks RPTroll,

I will try version b91 then in that case and see if it fixes the problem. I assume it is best to have the GM and other players using the same version.

As for the 5mb stack size, I had been using it for over a year on my old 4GB ram machine without an problems. We moved to 5mb after a few of our personal macros started stopped working at 4mb. I would hope this isn't the problem on my new machine but will try to drop it and see if that improves the chat stability as well.

Cheers,
Hyperion

[RPTroll]

Regarding the macro, you either have a lot of text coming out or a lot of comments in the macros. You can drop the stack size by putting all that in a var then dumping that out at the end. I got rid of my comments by putting those into a junk var as well. A comment will look something like

Code: Select all

<!-- some comment -->

I wonder if the chat problem has something to do with the amount of text that being dumped into the window. I don't know what the maximum size is but I had folks lock up when I put a license statement into the OnCampaignLoad macro. Some it worked fine on, others it locked up. Can you isolate the problem to when these large macros are being run? You can set the stack size back, forgo the macros, and see if you can recreate. If a chat flood is the issue then you can go back and redo the macros using the method above.

[Hyperion wildfire]

My macros do typically output a lot of text to the chat window yes so I can try to cut this back to drop the stack size. I'm a very sloppy coder (in general) so comments are rare to none existant in my macros.

That said I dont beleive that is what is causing the lock up. The macros run fine when I use them (even when conected to other players) the lock up only occures when someone else trys to type something into the chat box. This can be other players running macros but it also happens with something as simple as my GM saying hello.

I have yet to get another member of my group online to try out some of these solutions but I will test them as soon as I do.

Cheers
Hyperion

[Hyperion wildfire]

So I was able to gt my GM online last night to try out these solutions.

We initially tested again with my previous set up, My GM started a server and I coneccted, once the campaign had loaded he imidiatly tried to send me a message in the chat box to see if the lock up still occured.
I saw the warning the he was typing which hovers over the map area and everything was fine but as soon as he hit enter to send the message (just the word 'hello') maptools locked up and I had to forceably kill the java process.

We then attempted the exact same experiment using the latest version of maptool (1.3_b91). No change, once again I see the warning that he is typing and maptools locks up as soon as he tried to send the message to me (again just the word 'hello').

We repeated the test a few times with both builds to make sure this was consistently happening. Interestingly maptools does not lock up if I have the chat window closed when and the GM sends messages so it looks like it does have something to do with the text being output into the chat box.

We then performed similar tests using the initiative tracker with both builds. It works fine until it moves onto a player character at which point maptools locks up (I beleive this is related to the chat box again as when the initiative tracker moves to a player character a mesage saying that they received initiative is usually output into the chat box). Unfortunatly this lock up occured even when I had the chat box closed.

Finally we tried dropping the stack size down to 3mb, and repeated the above experiments, each time with the same results. I ran all of the above experiments with the Java console open to display the menory useage incase this was the problem, throughout all the tests the heap memory useage never went above 560MB and there where always less than 40 threads running. Im not familiar with java so I do not know how much memory each thread uses but I would guess the total is well bellow the 16GB avalible on my laptop.

I also checked the macros and ran a number of my own character macros which output a lot of text to the chatbox. These all worked without any problems when I ran them on my machine while conected to the GMs server. I was also able to type messages into the chatbox and send them without any lock up however when my GM tried to run the macros or type anything into the chat box Maptools locked up.

Cheers,
Hyperion

[Full Bleed]

Since I've never heard of this, it's almost certainly a Linux thing.

That's where your attention should be focused.

[RPTroll]

I run linux and don't have a problem. I seem to recall something about chat notifications a long time back but that bug should be long gone.

Still, it may be worth a try.

To test, go to Edit->Preferences
Find the Chat section on the right hand side
unclick "Show Chat Notifications Background" and rerun your tests.

I hold out little hope it will fix it, however.

[Hyperion wildfire]

Hi again,

Finally got the group back together after everyone being away to test this and as RPTroll suspected it made no difference. The option was infact already off in my version of Maptool but I got my DM to disable it on his before doing the tests.

I had another thought though, is it possible this problem is being caused because I have 64bit java rather than 32bit java running on my machine. I only ask because I noticed that my old machine (which ran Maptool perfectly) was running 32bit java 6 despite being a 64bit machine. Unfortunatly the repository that I installed Java from doesnt give the option of 32 or 64 bit but if it is possibly the problem I can remove the current version and do a manual install of a 32bit vesrion if thats what I need.

Cheers,
Hyperion

[Full Bleed]

I had another thought though, is it possible this problem is being caused because I have 64bit java rather than 32bit java running on my machine.

*If* that's your problem then, again, it's very likely related to being a Linux install. This is a very unique problem (as you will not find this reported anywhere else.) It's not a great leap to recognize that there are far fewer MT Linux users than any other OS and that there must be a fairly unique condition/setting/driver (etc), likely related to Linux, that's causing the issue with your specific install--or someone in the greater majority (Win or OSX) would have already run into the problem at some point in time. I can tell you that there is no known problem running MT with 64Bit Java 7 on Windows machines, so I would look elsewhere from Java 64.

You can try 32 bit if you want to though... maybe this will help: http://java.com/en/download/help/linux_install.xml

But since it is specifically related to chat--

1) I might check my firewall and/or security programs to see if they are reacting to those specific data packets in an unexpected way.
2) Check your network card driver and settings.
3) Check the MT Network FAQ for various network driver settings that have addressed connection problems for specific network card chipsets.
4) Change the port you're using in MT to see if a different port will yield expected behavior.

PS: You should also post your About>Gather Debug Information here.

[Hyperion wildfire]

Thanks for the suggestions Full Bleed,

Installing 32bit Java isn't a problem, I have been using Linux systems for over a decade so I can handle the manual install of a Binary easy enough. However if you dont think this is likely to be a problem I will leave it as an option of last resort as the libraries required to run 32bit java on a 64bit system where removed from Ubuntu 14.04, as was the ia32-libs package which contained them so determining which libraries are needed and where I can find them could be quite involved for a solution you dont think will work.

I also noticed today that the problem persists when conecting two instances of maptools running on my own computer. Im not sure if this changes any of your networking suggestions but it means i can test suggetions more quickly.

1) I had no problems when running this on my old windows machine so I do not beleive the problem is with the firewall in my router. In anycase we are using Hamachi to conect which solved router firewall issues for others in my groups.

The firewall in Ubuntu is built directly into the kernal which means its not easy (im not sure its even possible) to remove it completely but it can be disabled. It is auto configured to allow all trafic anyway so it shouldnt be the problem but I disabled it and checked, and the problem persists.

2 & 3) I havent had a chance to look into these yet

4) I tested with a number of different ports, about 30, and none of these fix the problem.

As requested here is my gather debug information

==== MapTool Information ====
MapTool Version: 1.3.b91
MapTool Home...: ../../../.maptool
Max mem avail..: 227M
Max mem used...: 64M
Custom Property: -DMAPTOOL_DATADIR=../../../.maptool

==== Java Information ====
Java Vendor.: Sun Microsystems Inc.
Java Home...: /usr/lib/jvm/java-6-oracle/jre
Java Version: 1.6.0_45
Result of executing 'java -version':
............: Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
............: Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)


==== OS Information ====
OS Name........: Linux
OS Version.....: 3.13.0-44-generic
OS Architecture: amd64
PATH...........: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
Number of Procs: 8

==== User Information ====
User Name: stephen
User Home: /home/stephen
User Dir.: /home/stephen/Documents/Maptools/maptools-1.3_b91

==== Network Interfaces ====
Display Name..: ham0
Interface Name: ham0
Address...: fe80:0:0:0:7879fea8:cf92%4
Address...: 2620:9b:0:0:0:0cf92%4
Address...: 25.168.207.146

Display Name..: wlan0
Interface Name: wlan0
Address...: 2a01:e356340:8219fe0b:4b4%3
Address...: 2a01:e356340:a932:92b54c2d%3
Address...: fe80:0:0:0:8219fe0b:4b4%3
Address...: 192.168.1.41

Display Name..: lo
Interface Name: lo
Address...: 0:0:0:0:0:0:0:1%1
Address...: 127.0.0.1

Host Address...: 127.0.1.1
Default Gateway: 192.168.1.254

==== Locale Information ====
Country.: United Kingdom
Language: English
Locale..: English (United Kingdom)
Variant.:

==== Display Information ====
Number of Displays: 1
Display 1: 1920x1080(-1)

==== Internet Gateway Devices ====
Device Name.: Freebox Server
Model Name..: Freebox Server
Manufacturer: Freebox
Model Number: 6
Model Desc..: NAS/Modem/Routeur ADSL/FTTH
Firmware....: Linux/2.6 UPnP/1.0 fbxigdd/1.0
External IP.: 82.66.38.52


Cheers,
Hyperion

[Full Bleed]

I also noticed today that the problem persists when conecting two instances of maptools running on my own computer. Im not sure if this changes any of your networking suggestions but it means i can test suggetions more quickly.

This should really help.

2 & 3) I havent had a chance to look into these yet

When taking a look at the MT Networking FAQ (http://forums.rptools.net/viewtopic.php?f=22&t=3370) check out page 13 (#10). The issue in that case is usually an inability to stay connected to a server and it's not been noted with OSX and Linux... but it's the closest issue I can think of to what you're experiencing.

I don't know if you have access to your transmit buffer in linux, but if you do, I'd try increasing it.

MapTool Version: 1.3.b91
MapTool Home...: ../../../.maptool
Max mem avail..: 227M
Max mem used...: 64M

Please run MT with at least these settings: 1024M Max, 64M Min, 4 Stack. It probably won't solve this problem, but it will most assuredly solve future problems.

Java Home...: /usr/lib/jvm/java-6-oracle/jre
Java Version: 1.6.0_45
Result of executing 'java -version':
............: Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
............: Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

You should be using Java 7 with b89 and later. 64 bit should be fine (in fact, I highly recommend people use 64 bit if possible).

[RPTroll]

As stated, bumping the max memory and stack size may not solve this problem (but it might) and will help in the future.