-
May 6th, 2022, 22:04 #1
Beta 4.2.0: Updater somehow corrupts itself (on Mac)
Hi,
When switching between the TEST and LIVE instances on my Mac, it appears the updater somehow corrupts the "FantasyGroundsUpdater" app and as a result, after launching FGU and clicking on the "Update" button, FGU exits, but the updater never launches. The actual update program "FGUpdaterEngine" is still functional and I can launch that by hand and perform an update manually, but it appears when clicking on the "Update" button FGU tries to run the intermediate app "FantasyGroundsUpdater" and it fails. If I try to launch it by hand I get this message:
Screen Shot 2022-05-06 at 4.55.31 PM.png
The program appears to be present in my filesystem, but something about it is not liked by my Mac.
To recover so the "Update" button works again in FGU, I have to re-download the FGU install from the web site. Simply switching back to LIVE does NOT update the updater back into a working state. Re-downloading from the web site appears to be only way to get it working again. But, if I then try to test the beta, it breaks again.
I didn't think I had seen this issue initially on Tuesday when I was toggling between the beta and Live version. I'm pretty sure it started happening with the later update on Wednesday.
Cheers,
Brian
-
May 6th, 2022, 23:00 #2
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,561
I'm not sure what might be causing that, since the version of the FantasyGroundsUpdater.app appears to be correctly signed/notarized from our source control and patch system installs for both Live and Test. Also, I just updated back and forth on my Catalina machine without issue between the two channels.
I wonder if Apple had an update that changed permissions in some way over the last week; and maybe only on some platforms (M1 vs. Intel chips; Catalina vs. Monterey; etc.)
Regards,
JPG
-
May 7th, 2022, 02:06 #3
I poked around a bit more and figured why it stops working, but I don't know what specifically causes it, other than switching to the test version. The FantasyGroundsUpdater.app/Contents/MacOS/FantasyGroundsUpdater binary is not executable. If I do a "chmod a+x" of it, then it all works again without me having to re-download everything from the website. I can click on the "Update" button within FGU and it launches the updater as expected.
However, if I switch to the TEST instance via the settings and choose update, the FantasyGroundsUpdater loses the execute permissions again. It ends up looking like this:
-rw-r--r-- 1 mosttornbrain admin 5734208 May 6 21:01 FantasyGroundsUpdater
Something about switching to the test instance causes the loss of the execute permissions.
I am running Monterey, 12.3.1.
Cheers,
Brian
-
May 7th, 2022, 02:23 #4
Some more details that might be helpful. I noticed in the Smiteworks/FantasyGrounds application folder there is a FantasyGroundsUpdater.log file. It contains the following:
Code:didFinishLaunching. CurDir: /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater.app/Contents/MonoBundle/ START RunUpdater() AppDelegate:RunUpdater CheckNewUpdater(): /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater_NEW True New Updater Valid: True Recursive Delete: /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine Deleting parent /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine RecursiveCopy: /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater_NEW - /Applications/SmiteWorks/Fantasy Grounds CONTINUE LAUNCH: True Check path: /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine/FGUpdaterEngine.app exists: True UpdateExecutePermissions Standard input chmod LaunchApp() FGUpdaterEngine Process Started.
Code:/Applications/SmiteWorks/Fantasy\ Grounds/FantasyGroundsUpdater.app/Contents/MacOS/FantasyGroundsUpdater ; exit; didFinishLaunching didFinishLaunching. CurDir: /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater.app/Contents/MonoBundle/ START RunUpdater() AppDelegate:RunUpdater CheckNewUpdater(): /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater_NEW True New Updater Valid: True Recursive Delete: /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine Deleting parent /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine RecursiveCopy: /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater_NEW - /Applications/SmiteWorks/Fantasy Grounds CONTINUE LAUNCH: True Check path: /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine/FGUpdaterEngine.app exists: True UpdateExecutePermissions Standard input chmod /bin/bash: line 1: chmod: command not found LaunchApp() FGUpdaterEngine Process Started.
Perhaps the updater is attempting to do a chmod of the newly updated FantasyGroundsUpdater, but there's some extra unicode encoding in front of the chmod so it isn't recognized properly as a valid shell command?
Just spitballing ideas here. Let me know if there is anything else that might be helpful to try to get to root cause for this.
Cheers,
BrianLast edited by MostTornBrain; May 7th, 2022 at 02:25.
-
May 7th, 2022, 15:35 #5
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,561
Thanks for the additional information.
The odd thing in this situation is that the version of the FantasyGroundsUpdater.app executable has not been updated in almost 9 months; and both the Test/Live builds are using the same version of the executable.
Also, on both my Mac and on our tester's Mac, we are not seeing that issue. I think we are both running Catalina (since we only have two Macs internally for build and testing). I don't know if that's the difference, but seems weird that characters would be inserted just based on OS version difference.
Regards,
JPG
-
May 7th, 2022, 15:41 #6
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,561
I didn't write this code personally; but here's what's in the file for that section. I'm not seeing anything that looks incorrect, or any special characters in the code. I even opened in a text editor that allows viewing of all hidden characters, but there are no hidden characters in the code (just tab/CR/LF around the code as expected).
Code:static void UpdateExecutePermissions() { Log("UpdateExecutePermissions"); ProcessStartInfo proc = new ProcessStartInfo("/bin/bash"); proc.WorkingDirectory = AppDirectory(); proc.UseShellExecute = false; proc.RedirectStandardInput = true; proc.RedirectStandardOutput = true; Process p = new Process(); p.StartInfo = proc; p.Start(); Log("Standard input chmod "); p.StandardInput.WriteLine("chmod -R 777 FantasyGroundsUpdater.app"); p.StandardInput.WriteLine("chmod -R 777 FGUpdaterEngine/FGUpdaterEngine.app"); p.StandardInput.WriteLine("chown -R $(whoami) FantasyGroundsUpdater.app"); p.StandardInput.WriteLine("chown -R $(whoami) FGUpdaterEngine/FGUpdaterEngine.app"); //p.StandardInput.WriteLine("exit"); p.StandardInput.Flush(); System.Threading.Thread.Sleep(500); }
JPG
-
May 7th, 2022, 19:33 #7
- Join Date
- Nov 2018
- Posts
- 389
Just a guess, but it looks like the <U+FEFF> you're seeing is a byte order mark, and from your log it appears it's only before the first chmod command (at the start of the input stream to the process). Though, I'm not sure what might cause that to be written, maybe some encoding related setting in your environment?
-
May 7th, 2022, 21:01 #8
That is a good observation that only the first chmod fails. That would lead to pointing to that stray UTF character already in the output buffer before the script contents are written. I wonder if writing a blank "CR/LF" before that first chmod might fix it. I have confirmed by manually changing the file permissions of FGUpdaterEngine/FGUpdaterEngine.app that they do get changed back to 777 after the script runs. So, it appears it is indeed just the first chmod that is failing.
I have also confirmed that the missing chmod error doesn't show up in the FantasyGroundsUpdater.log file because it is sent to STDERR. If I run FantasyGroundsUpdater via the following command line, the error does show up in the log file:
Code:./FantasyGroundsUpdater > mylog 2>&1
Cheers,
Brian
-
May 7th, 2022, 23:41 #9
This might be a wild stretch, but it looks like someone else has run into what appears to be similar issue with Unity and StandardInput.Writeline() doing something odd with extra character encoding: https://forum.unity.com/threads/c-st...solved.410154/
Not sure if the code in question for the FantastyGroundsUpdater is using the same library or not, but thought it would be worth mentioning.
Cheers,
Brian
-
May 8th, 2022, 01:11 #10
One more update - hopefully this is a helpful observation. If I change my terminal default encoding from "en_US.UTF-8" (which I believe is the macOS default) to "en_US.US-ASCII" then the problem with the first chmod failing goes away when I run FantasyGroundsUpdater by hand. However, it still appears to fail behind the scenes when switch from TEST back to LIVE FGU. Changing the terminal app default encoding doesn't affect the updater when it is launched by FGU.
Cheers,
Brian
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks