maptool
maptool copied to clipboard
RPTools
macOS sometimes gets "spinning pinwheel" when closing a panel
For me, when running inside of Eclipse, this procedure produces the spinning pinwheel of death more times than not:
- Start MapTool.
- Make campaign macro panel visible, if it's not already.
- Right-click and add a new macro.
- Right-click on the new macro button and choose Edit.
- Click Cancel.
Perhaps related to https://bugs.java.com/bugdatabase/view_bug.do?bug_id=7081670 ? I tried moving the dispose() call into an invokeLater() callback and that cleared it up for that case, but I haven't tested other cases.
Eclipse says there are 23 references to that function in the current code base, so a proper fix is to subclass JDialog with our own class and override dispose()?
how is this one looking? I'm going to move to in-progress as I believe you have most of the code in?
Be sure when it's merged to add a "Fixes #issueNumber" to the PR. It's handy to have that on the commits to as it then logs to the issue and we can see progress if any.
The fix didn’t work in a quick test of something else last night. Not sure where it’s at now, but I’ll take ownership.
Thanks! For context, which versions of MapTool does this affect? Is it only happening in the latest branch targeting 1.5?
I've seen it in 1405 as well. I don't think this is as much a bug in MapTool as it is an interaction between the Java runtime and Apple's platform-specific libraries that might require using a workaround in MT.
This doesn't look like something quick or easy to fix so moved out of current release.
As of 1.6.0-alpha-4, this is still happening to me. Apple's SIP (System Integrity Protection) gets in the way of diagnosing it.
I did find that if I cleared the tmp directory created at user login (?), the Spinning Pinwheel of Death (SPOD) would be delayed significantly. It seems I need to do something along the lines of:
sudo rm -rf "$TMPDIR"
... followed immediately by logging out and back in. Afterwards, I was able to use MT for roughly 30 minutes of window open/close events before I got the SPOD again. I let it sit and it cleared itself after about 6-7 minutes. I have not cleared the directory again, but only got a few minutes of use out of MT before the SPOD was back. (And this time, I've got 8 minutes and running without it clearing...)
Since a newly created user account doesn't show any signs of problems, I'm convinced there's a file being stored somewhere that affects this. I've just found out about opensnoop utility and similar tools, so I'm going to try to isolate exactly which files are being accessed between my MT and the one for a new account. But as mentioned at the top, SIP gets in the way...
An update...
I've been working on this some more. It basically makes MapTool unusable for me. I've had it happen even while in Eclipse, but pausing the app doesn't help much when there are 30+ threads sitting out there, most of them unnamed. (Although it's clear that it's the EDT being blocked that causes the problem, it's not clear why it's being blocked.)
In any case, I've tried modifying my boot up sequence so that the above rm command is executed when I reboot. Initial tests show that this corrects the issue, but I need more testing. Note that some of the files and directories under $TMPDIR will be protected and can't be removed, so doing the cleanup at boot time seems to be required. More testing is needed.
Are any other Mac users seeing this?
I know that my wife never saw this with 1.4.0.5 (which we used for dozens of sessions) on her iMac.
We had one report on Discord. I pointed out that a different user id on the same system doesn't have this issue and they were using that as an interim solution. It clearly doesn't affect many people or we'd be hearing about it a LOT more.
Have you tried a newer/different version of Java? Should be able to do it locally with some adjustments to the gradle build.
You mean different from 10.0.2? I've tried to get a later one working (when JDK 12 was released, I think) but that was a rabbit hole that was much deeper than I wanted to go. (Particularly since I was doing on my laptop and not in a VM, meaning rolling it back could get painful all by itself.)
Ya, like with 13 or 14. Should be able to get around the FX requirements easy enough by just adding the new FX dependencies. I haven't done it because we have native images we need to support anyway so no sense in adding it yet, but been meaning to test jdk 14 anyway...
I used the code above and logged out and in again. But 1.6.0 still shows only launcher (on the admin account. Other account on the iMac works.
Hm. Thanks for the data point. I'll have some time next week and I'll try to dig into this more. The cleanup of the $TMPDIR directory has been working pretty well for me lately; I can go hours before needing to clean it again. I've tried making a list of files in that directory, then letting the error occur and making another list so that I can compare the before-and-after, but that hasn't pointed to any particular subsystem...
If you're experiencing this problem, please indicate any third-party software you have installed. I'll go first.
. Homebrew (with a large selection of software) . Fink (used to use fink, but mostly disabled and just taking up disk space now) . Anaconda Python 3.7 . Multiple versions of Acrobat Reader (and Acrobat Pro 9) . Adobe Elements . MacVim . Atom . VSCode . PyCharm and WebStorm . Eclipse
In fact, speaking of Eclipse, I've had Eclipse do the same thing, although it's only happened twice whereas it happens frequently with MapTool. I mention this because Eclipse is also written in Java, so are PyCharm and WebStorm and I've not seen it happen in either of those.
I have a LOT of other software installed, too long a list. I'll generate such a list programmatically and then copy/paste it into this message sometime this coming week.
I’ve completely reinstalled Catalina on the affected laptop and I’ve only seen this issue once. I was careful NOT to use the Migration Assistant and just copied files over myself, expecting that this would leave my ~/Library cleaner. A brand new laptop has (so far) not demonstrated the problem either. I plan to slowly install additional software on the new laptop and try to use MT extensively between packages to see if there’s a particular app that is exacerbating the problem.
I've heard JDK 14 has really helped with the various spinning wheels off death, so keep that in mind as well for testing.
Using html5 function (frame5(), dialog5() and overlay()) always occured spinning pinwheel and hanged up MapTool.
- Open Campaign Panel.
- Create new macro button.
- Write code
[frame5("foo"):{<button>Click me</button>}]and Run. - Click the button or move the frame several or any number of times.
- Occuring pinwheel and MapTool is hanged up.
I tried Azhrei's workaround, but couldn't sovle the promblem.
(running rm -rf "$TMPDIR" and creating new user account)
Caveat: I am not a programmer, so while I am willing to do what I can to help troubleshoot this, I may lack either the tools or experience to help without some hand holding.
I am experiencing hangs and massive CPU consumption with Maptools 1.5 and 1.7. I can reliably reproduce it in one of two ways.
- In both Mojave and Catalina, If Default Folder X (a Finder enhancement tool) is running, opening the edit token button is all it takes.
- In Mojave, if I attempt to export or import campaign properties.
Let me know how I can provide further information!
Let me know how I can provide further information!
Based on what you said in Discord, it sounded like a separate user account solved this issue for you. Is that correct? (Obviously, that's not a long-term solution, just a data point in trying to narrow down the cause.)
I said I had used Homebrew and you indicated you had done the same. I have run this command line and I will continue to do so whenever I install something new. If/when something causes the SPOD again, I should have a before-and-after list. Maybe that will help...?
(date; brew list --versions) >> ~/.brew-app-log
What about other dialogs? For example, it happened to me any time I opened any dialog, including Campaign Properties, Preferences, or even a macro that executes the input() function.
I see the same issue on my Mac (Mojave). How can I assist in debugging this problem?
We have discovered so far that creating another user account and running MapTool from that account clears the issue. So there must be something that is installed under the original user's account that causes the issue. As you can see from the thread above, we haven't narrowed it down yet. If you have the motivation to set up a new account and then recreate your original account settings (loading software or configuring application preferences or whatever else it takes), perhaps you could narrow down specifically which application(s) are causing it.
The problem is... that's a large ask.
It's clear that the Java runtime is getting into some kind of contention with other installed software, but I don't have the (macOS) expertise to be able to tell which other application is causing it. (I've reinstalled Catalina on my laptop and by NOT using the migration assistant, I haven't had the problem return.)
In the past I used VisualVM to pause the application when the SPOD showed up. It was invariably paused inside the LockSupport.park/unpark calls, which are a synchronization API within the JVM.
Some web searching shows that there have been various bugs filed over the years, but I don't see anything currently open against Java 10 (although searching the bug database is extremely spotty).
You can try searching for LockSupport and/or park unpark to get an idea.
However, this doesn't appear to be an application bug (that I can tell, at least; you can read through the thread for what I've tried).
I created a new user account on my Mac, and installed MapTool 1.7.0 locally for that user. I did not run into the beachball problem anymore like I did on my regular Mac user. I preserved the output of "ps auxwwSr" to compare when the beachball happens again.
I preserved the output of "ps auxwwSr" to compare when the beachball happens again.
Hm, that's a good idea; it's only going to be running programs that should affect it. I would suggest using ps -o command | sort instead, since that will make it easier to compare one snapshot against another. You can probably even do that between different accounts as a way to narrow it down.