Kaju self-updater talk (v.2.x)

  1. ‹ Older
  2. 3 months ago

    Derk J

    Apr 10 Testers, Xojo Pro
    Edited 3 months ago

    @Austin G Hmm, thanks Derk, it's not that then! The app does seem to be borking when constructing a FolderItem using the stored SaveInfo though, and the debugger is showing this content as binary. The old docs for FolderItem.GetSaveInfo clearly state that this is a String representation of the path, so it seems something has changed.

    The SaveInfo and GetSaveInfo both returned a special string, it's not only a path. It made up of a specific line, not to be changed manually.

    You'd only use the result to load back into FolderItem.FromSaveInfo so you know where the file should be (if it's still there...)

    The docs are unclear there i think. or i may be wrong with the new api @Paul L ?

  3. Beatrix W

    Apr 10 Testers, Third Party Store Europe (Germany)

    I made a super crude workaround: https://forum.xojo.com/58323-kaju-admin-app-crashing

  4. @Beatrix W 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!

  5. @Aurelian N 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…

  6. Kem T

    Apr 10 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    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?

  7. 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.

  8. Kem T

    Apr 10 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I thought I trimmed that, but I guess not. I'll look at that at some point.

    Glad it's working now.

  9. @Kem T I thought I trimmed that, but I guess not. I'll look at that at some point.

    You did. I was using vi to edit the file directly on the server. Like an idiot.

  10. Kem T

    Apr 10 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I agree, vi is evil.

    ducks and runs...

  11. Douglas H

    Apr 10 Testers, Xojo Pro

    @Kem T I agree, vi is evil.

    It's even embedded in the name ...

  12. Norman P

    Apr 10 Testers, Xojo Pro outside admiring the sunshine,...

    vi is just ubiquitous on Unix distros including macOS :P

  13. Edited 3 months ago

    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))]
  14. Kem T

    Apr 16 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    This is outside my wheelhouse, sorry.

  15. 2 months ago
    Edited 2 months ago

    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: Feedback Case #59800

  16. 7 weeks ago

    Kem T

    May 14 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    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.

  17. Douglas H

    May 14 Testers, Xojo Pro

    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.

  18. Kem T

    May 14 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    Are you storing an instance of UpdateChecker in a property or a local variable?

  19. Douglas H

    May 15 Testers, Xojo Pro

    @Kem T 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 if

    However, 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 Sub
    Private Sub HandlePostCheck(checker as Kaju.UpdateChecker)
       ... code which sets up a MsgBox when applicable ...
    End Sub

    Aside 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 Function

    So 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?

  20. Kem T

    May 15 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    Yes. My sample code was originally synchronous, so if it's still doing that, I should change and document it.

  21. Kem T

    May 16 Testers, Xojo Pro, XDC Speakers, MVP Connecticut
    Edited 7 weeks ago

    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.)

  22. Newer ›

or Sign Up to reply!