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

  1. ‹ Older
  2. 3 months ago

    Douglas H

    Mar 10 Testers, Xojo Pro

    I've been successfully using Kaju v2.1 for macOS updates for all but one user, who never got the prompt an updates was available, whether or not a silent check was being made. The app menu option to check for an update never displayed any result, even if simply "No updates available".

    It was only a single user with this issue, and was friendly and didn't really mind having to install himself when I sent links, but it always struck me as odd. He did not have the firewall turned on, or anything other malware or virus detection software active, but I still attributed it to something unique about his machine.

    This weekend we were in the same city, so he gave me a chance to sit together and debug the issue. And to my initial surprise, when I stepped through the code in debug it worked and told me there were no updates available. So then I removed all my breakpoints but still ran in debug mode and it still worked. Compiled the same source, and it failed to report anything! So I figured it had to be timing dependent, and looked closer at how Kaju.UpdateCheckerFetchAsync performed this section of code:

    dim url as string = UpdateURL
    dim http as Kaju.HTTPSocketAsync = GetAsyncHTTPSocket
    http.Get url

    with the GetAsyncHTTPSocket method doing this:

    if AsyncHTTP is nil then
      AsyncHTTP = new HTTPSocketAsync
      AddHandler AsyncHTTP.PageReceived, WeakAddressOf AsyncHTTP_PageReceived
      AddHandler AsyncHTTP.Error, WeakAddressOf AsyncHTTP_Error
    end if
    
    return AsyncHTTP

    So on a whim, since it seemed to be timing dependent and since I already had the MBS plugins available, changed to this:

    if AsyncHTTP is nil then
      AsyncHTTP = new HTTPSocketAsync
      AddHandler AsyncHTTP.PageReceived, WeakAddressOf AsyncHTTP_PageReceived
      AddHandler AsyncHTTP.Error, WeakAddressOf AsyncHTTP_Error
    end if
    
    // Add slight delay to allow time for AddHandlers to complete
    SleepMBS(0.05)
    
    return AsyncHTTP

    to add a 1/20 second delay before the socket was returned.

    It then worked even in compiled mode. This user's machine was the fastest of any of my users -- including me -- and it at least seems the socket was getting returned and the .Get url completing faster than the AddHandler's had taken effect. Or so it seems.

    And perhaps 0.05 seconds is overkill and another shorter delay tactic would suffice. But I'm ok with adding 1/20 second delay into an operation so am just leaving it as it for now.

    So this is more for the sake of reporting the issue I saw and the eventual circumvention in the hopes of helping others.

    This was using Kaju v2.1, and Xojo 2019R1.1, with client machine running 10.14.16 (Mojave) with firewall etc off.

  3. 8 weeks ago

    I've just tried implementing Kaju into a project and I'm getting problems in Xojo 2019 r3.1.

    When saving a configuration from the Kaju admin app, it throws an UnsupportedFormatException from the Kaju FolderItemAlias.Resolve method, at the point that it's constructing a FolderItem using previously stored zSaveInfo.

    I haven't modified the admin app at all, so am I doing something wrong or perhaps missed a setup step?

  4. Beatrix W

    Apr 10 Testers, Third Party Store Europe (Germany)

    I posted a workaround a while ago. But I don't remember what I did to fix the problem.

  5. @Beatrix W I posted a workaround a while ago. But I don't remember what I did to fix the problem.

    Ok, as it's not me, I've done some more digging and as far as I can tell this might be related to FolderItem.GetSaveInfo which returned a String being deprecated and replaced by FolderItem.SaveInfo, which now returns a MemoryBlock. Although the official documentation seems confused about this (the docs for FolderItem.FromSaveInfo state it takes a String as its parameter, which I can't believe is correct) and the compiler doesn't seem to care either.

    What confuses me is that various people have clearly been using Kaju successfully recently (active conversation thread above) without encountering this issue.

  6. Derk J

    Apr 10 Testers, Xojo Pro

    @Austin G Ok, as it's not me, I've done some more digging and as far as I can tell this might be related to FolderItem.GetSaveInfo which returned a String being deprecated and replaced by FolderItem.SaveInfo, which now returns a MemoryBlock. Although the official documentation seems confused about this (the docs for FolderItem.FromSaveInfo state it takes a String as its parameter, which I can't believe is correct) and the compiler doesn't seem to care either.

    What confuses me is that various people have clearly been using Kaju successfully recently (active conversation thread above) without encountering this issue.

    String and memoryblock are essetially the same.

    Var myString As String = "hello world"
    Var myMB As MemoryBlock = myString
    
    Var output As String = myMB
    
    System.DebugLog(output) // Reads "hello world"
  7. @Derk J String and memoryblock are essetially the same

    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.

  8. Derk J

    Apr 10 Testers, Xojo Pro
    Edited 8 weeks 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 ?

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

  10. @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!

  11. 7 weeks ago

    @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…

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

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

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

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

  16. Kem T

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

    I agree, vi is evil.

    ducks and runs...

  17. Douglas H

    Apr 10 Testers, Xojo Pro

    @Kem T I agree, vi is evil.

    It's even embedded in the name ...

  18. Norman P

    Apr 10 Testers, Xojo Pro outside LMAO !!!!!!!

    vi is just ubiquitous on Unix distros including macOS :P

  19. Edited 7 weeks 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))]
  20. Kem T

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

    This is outside my wheelhouse, sorry.

  21. 6 weeks ago
    Edited 6 weeks 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

  22. Newer ›

or Sign Up to reply!