I made a super crude workaround: https://forum.xojo.com/58323-kaju-admin-app-crashing
You rock, thank you Beatrix. I was looking at something vaguely similar but hadn’t quite worked out what the purpose of the FolderItemAlias is in the first place. Then I got distracted by another task!
@Aurelian Negrea Did you ever get to the bottom of the error your reported in 2018:
The RSA signature of the update packet cannot be verified.I think I have got everything set up and working, built and deployed onto my hosting, including notarizing the Mac application, but Kaju is throwing the above error every time I launch the app. I have triple checked that the RSA key I set with UpdateChecker.ServerPublicRSAKey is identical to the Public Key from the admin app. Even grabbed the public key from inside the .kaju file just in case the ‘Copy’ operation somehow munged the key. Still throws the error every time
I wonder if the file is getting modified somehow between being signed and getting sent to your app. Can you do a diff between the saved file and what your app receives?
Erm, cough, mumble. A linefeed might have accidentally crept into the end of the file. Sorry 
Thanks for all the hard work on this btw Kem.
I thought I trimmed that, but I guess not. I’ll look at that at some point.
Glad it’s working now.
You did. I was using vi to edit the file directly on the server. Like an idiot.
I agree, vi is evil.
ducks and runs…
It’s even embedded in the name …
vi is just ubiquitous on Unix distros including macOS 
Well, now I’ve got past evil stupidity, I’ve fully implemented Kaju on my project and it’s working perfectly on Mac and Windows. However
(there’s usually one of those)
On Linux (testing on Ubuntu at the moment, both 18 and 19 and the Elementary OS derivative) my application crashes hard if the version check results in no newer version available (i.e. KajuUpdateWindow is not shown). If it shows the window, even if I cancel the process, there are no problems.
By crash hard I mean immediate CTD whether running through the remote debugger or not - no exception thrown just bang! If I run from the command line I get Segmentation fault (core dumped)
I’ve tried putting breakpoints in various places throughout the UpdateChecker class and as far as I can see it gets all the way through the Async fetch, parse and finishes cleanly. At some point after that the crash occurs.
Note that I’m making no other changes to the project: If I set the version to 3.0.0b1 everything works fine (because there’s a b2 available on the server) while if I set the version to 3.0.0b2 it crashes.
Analysing the core dump with gdb (just learned this) gives the following:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f5c220bea31 in ?? ()
from /home/parallels/OpenSceneryX Installer/OpenSceneryX Installer Libs/XojoGUIFramework64.so
[Current thread is 1 (Thread 0x7f5c244dfa80 (LWP 27056))]Anybody come across anything like this, or have an idea how to track down the root cause?
Edit: As a followup, I tried running it a few times and the core dump analysis actually changes. I can get:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000237b780 in ?? ()
[Current thread is 1 (Thread 0x7fbd16ebda80 (LWP 28063))]and also sometimes:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f5c2b5f0c60 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
[Current thread is 1 (Thread 0x7f5c2e070a80 (LWP 28543))]This is outside my wheelhouse, sorry.
I would like to raise a ticket in Feedback, but I suspect Xojo support will just ask me to supply a minimal example project that exhibits the problem, which is impossible to do as I have no idea what’s causing it. Might just submit the core dump anyway and see what happens.
Edit: Feedback case: <https://xojo.com/issue/59800>
I’m getting ready to release an update, and I could use some help testing.
Please take a look at this branch:
https://github.com/ktekinay/Kaju/tree/feature/To_URLConnection
The README contains all (well, most) of the changes since the last release. If there are any issues, please let me know.
I don’t have a way to easily test the problem I described in my Mar 10 post above, because it seems to only happen on faster hardware than I own. But refer to my Mar 10 post for a description of what I encountered with one user with a fast MBP. I’m sure you won’t want to use my listed circumvention because I slipped in a call to a MBS function since I license them. But you could do something similar without MBS.
If you don’t implement something like that, I’ll probably continue to slip in the MBS call in the versions I use myself.
My one user who had the problem uses it in large sports events which are completely shut down for the season and won’t even run the applications again until next year.
Are you storing an instance of UpdateChecker in a property or a local variable?
Sorry for the delay; was not in the office earlier.
To answer your question, yes, it is in a local variable but IIRC the code I use came from a sample project (of yours?).
In App, I declare app public property mKajuPrefsAppPath (type FolderItem) and app public property UpdateInitiater (type Kaju.UpdateInitiater). Then at the end of App.Open(), after setting up the mKajuPrefsAppPath, there is this block of code:
// If we have app prefs folder, initialize update check
if mKajuPrefsAppPath <> nil and mKajuPrefsAppPath.Exists then
dim checker as new Kaju.UpdateChecker( mKajuPrefsAppPath )
checker.AllowRedirection = true
checker.ServerPublicRSAKey = kKajuPublicKey
checker.UpdateURL = kKajuUpdateURL
// Only check for final versions not previously ignored
checker.AllowedStage = App.Final
checker.HonorIgnored = true
// Only allow window if update is available
checker.AllowedInteraction = Kaju.UpdateChecker.kAllowUpdateWindow
AddHandler checker.ExecuteAsyncComplete, WeakAddressOf Checker_ExecuteAsyncComplete
checker.ExecuteAsync
end ifHowever, in App there are two private methods which IIRC were copied from a sample project of yours:
Private Sub Checker_ExecuteAsyncComplete(sender As Kaju.UpdateChecker)
'#pragma unused sender
HandlePostCheck sender
End SubPrivate Sub HandlePostCheck(checker as Kaju.UpdateChecker)
... code which sets up a MsgBox when applicable ...
End SubAside from the above App.Open() check, there are also menu items for checking for beta or final updates. The main MenuHandler for checking for (final, non-beta) updates is:
Function OptionsCheckUpdate() as Boolean Handles OptionsCheckUpdate.Action
// See App.Open for some required setup
// If we have app prefs folder, initialize update check
if mKajuPrefsAppPath <> nil and mKajuPrefsAppPath.Exists then
dim checker as new Kaju.UpdateChecker( mKajuPrefsAppPath )
checker.AllowRedirection = true
checker.ServerPublicRSAKey = kKajuPublicKey
checker.UpdateURL = kKajuUpdateURL
// Unlike app startup checks, show ignored final versions also
checker.AllowedStage = App.Final
checker.HonorIgnored = false
// Allow window all the time (even if error etc)
checker.AllowedInteraction = Kaju.UpdateChecker.kAllowAll
AddHandler checker.ExecuteAsyncComplete, WeakAddressOf Checker_ExecuteAsyncComplete
checker.ExecuteAsync
else
MsgBox "Unable to check for updates" + EndOfLine + EndOfLine + _
"No preference file path is available. Please contact support."
end if
Return True
End FunctionSo in bothApp.Open() and my menu handler it is creating a local variable instance of UpdateChecker. However, I thought I had copied or at least patterned those blocks of code from a sample project.
And it always worked as expected for all but one user, who never got notified of updates in the App.Open() check and never received a MsgBox at all from the menu handler option (whether or not he was on the current version – he got no MsgBox at all).
We happened to be at the same large sporting event in early March and we had a little time for me to investigate. First I tried remote debug, which ran as expected and gave the update window or MsgBox. So then I installed unlicensed Xojo on his MBP and the project source and ran in debug mode. It still worked.
So then I figured it was timing dependent and inserted the .05 sec sleep in Kaju.UpdateChecker.GetAsyncHTTPSocket as described in my Mar 10 post, compiled on my MBP, and ran on his machine and then it worked. We didn’t have more time, so I didn’t try to narrow it down farther. And then after flying home from that sports event, the entire sport got shut down and the app may not be used at all again until next year. 
If you don’t recognize the above code I use in App.Open() or the menu handler, I can try to determine where I got those code blocks. But I was thinking they came from a sample project of yours.
Ahh, after typing all of the above, I just realized why you were asking. Your theory is that the App.Open() or menu handler completes and goes out of scope destroying the UpdateChecker instance before it can get an async response?
Yes. My sample code was originally synchronous, so if it’s still doing that, I should change and document it.
I just looked and the example test app is storing the UpdateChecker in a property. This is recommended, even required, for any object that acts asynchronously, but I imagine others will use local variables too and rely on the event handler to return the instance. As such, I’ll change the code in an attempt to compensate by forcing the instance to be kept alive until the data is fetched.
Edit:
This is why I should look before posting. The code already holds an instance during the async operation, so whatever the issue, that’s not it.
(A little bragging here: I often have “I should have thought of that!” moments only to find out that, yes, I did think of that. This is totally a triumph as a programmer, and in no way indicative of a poor memory.)
@Douglas Handy , the To_URLConnection branch now uses a Timer to start the URLConnection after it is set up. If this really is a timing issue, this should fix the problem. At worst, it introduces an 10 ms delay during which the user can wash their hair or catch up on Netflix.