webapp self-closing after new xojo version used

  1. 6 months ago

    Lars L

    3 Jan 2018 Europe (Germany, Chemnitz)

    Hi,

    one of our webapps closes itself "randomly" and our customers loosing the connection. After that we have to manually restart the app on our webserver.

    This behavior occurs since we updated our xojo IDE from 16R3 to 17R2 in december. We didn't change any code since this, we just build the app with the new Xojo version.

    Does someone else have seen this behavior as well? How can we fix this?

  2. Greg O

    4 Jan 2018 Xojo Inc Somewhere near Raleigh, NC

    @Lars L Hi,

    one of our webapps closes itself "randomly" and our customers loosing the connection. After that we have to manually restart the app on our webserver.

    This behavior occurs since we updated our xojo IDE from 16R3 to 17R2 in december. We didn't change any code since this, we just build the app with the new Xojo version.

    Does someone else have seen this behavior as well? How can we fix this?

    Do you have code in App.UnhandledException to record any new exceptions that might be occurring?

  3. Lars L

    11 Jan 2018 Europe (Germany, Chemnitz)

    We analyzed some things.

    the xojo-js-framework prints in the moment of the closing of the app the following to the console:

    [Error] Failed to load resource: the server responded with a status of 502 (HTTP/2.0 502) (e89iH8rR.Action, line 0)
    [Log] HTTP Error: HTTP/2.0 502 (framework.js, line 2139)

    We have a deamon in background, which starts a quited instance instantly, so I cant provide the content of the e89iH8rR.Action. I'll post it here later, we're about make our logging better.

  4. Greg O

    11 Jan 2018 Xojo Inc Somewhere near Raleigh, NC
    Edited 6 months ago

    That error is not coming from your web app. There's no place where we respond with HTTP/2.0.

    Now it could be showing up in the error dialog, but all that means is that when the Action event fires (probably a Timer or a Button), the web server on where you are hosting your app is returning the 502 error.

  5. Lars L

    12 Jan 2018 Europe (Germany, Chemnitz)

    okay, we inspected something else. right before the moment the app closes, on our server the server-cpu-usage of a wait I-O process rises.

    We have six identical instances of the same app running on our system, and just the app which is build using the last Xojo version shows this behavior...

  6. Greg O

    12 Jan 2018 Xojo Inc Somewhere near Raleigh, NC

    Sounds like the app may be crashing then. It’s possible that the minimum system requirements or the required libraries changed somewhere during the year. Try running ldd yourAppName to see if a required library is missing.

  7. Lars L

    15 Jan 2018 Europe (Germany, Chemnitz)
    Edited 6 months ago

    I've done that before, seems that all dependencies are installed:

    linux-vdso.so.1 => (0x00007ffef8dc8000)
    XojoConsoleFramework64.so => /[path_to_app]/via_20/./VIA_20_vms Libs/XojoConsoleFramework64.so (0x00007fe64c905000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe64c53c000)
    libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fe64c2eb000)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fe64bfe3000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe64bdc5000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe64bbc1000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe64b8bb000)
    libc++.so.1 => /[path_to_app]/via_20/./VIA_20_vms Libs/libc++.so.1 (0x00007fe64b50a000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe64b2f4000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe64ee13000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fe64b0ec000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fe64aeae000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe64aca6000)

  8. Greg O

    15 Jan 2018 Xojo Inc Somewhere near Raleigh, NC

    Just out of curiosity... was the 2016r3 version also built as 64-bit?

  9. Lars L

    15 Jan 2018 Europe (Germany, Chemnitz)

    yes, it was ;)

  10. Greg O

    15 Jan 2018 Xojo Inc Somewhere near Raleigh, NC

    I just looked through the release notes between 2016r3 and 2017r2 and I don't see anything obvious. If this happens consistently, it would be really helpful if :
    A. You could build with 2017r3 and see if it's been fixed,
    B. If not, if you could build with 2016r4 and 2017r1 and see where this actually broke.

    Narrowing it down may help us figure out exactly what broke this.

  11. Lars L

    15 Jan 2018 Europe (Germany, Chemnitz)

    Thanks Greg!
    We'll do this steps.

  12. Steve U

    Jan 18 Pre-Release Testers, Xojo Pro Seattle, WA

    This sounds like it might be a memory leak and the app running out of memory. I realize you've compiled for 64 bit but there are still limits on the physical memory available.

    I've seen similar errors with a different CGI-based system...

  13. Lars L

    Jan 18 Europe (Germany, Chemnitz)

    okay. hmm. but why does this happen just since the last xojo release?

  14. Steve U

    Jan 18 Pre-Release Testers, Xojo Pro Seattle, WA

    it's possible a new memory leak as snuck into the Xojo web server framework. Or perhaps different behavior in the framework has uncovered a memory leak in your code.

    I'd watch the memory use of the app over time and see if it rises before it crashes

  15. Lars L

    Jan 19 Europe (Germany, Chemnitz)

    @Steve U I'd watch the memory use of the app over time and see if it rises before it crashes

    It seems to be a Memory-leak as you said. :/ And it seems to be new.

    We now restart our AppInstances every night as workaround and start seeking for the leak.

    I'll file a feedback-case if it's xojo made.

    Thank you Steve!!!

or Sign Up to reply!