webapp self-closing after new xojo version used

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?

[quote=367243:@Lars Lehmann]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?[/quote]
Do you have code in App.UnhandledException to record any new exceptions that might be occurring?

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.

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.

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…

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.

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

[quote]
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)[/quote]

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

yes, it was :wink:

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.

Thanks Greg!
We’ll do this steps.

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…

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

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

[quote=369625:@Steve Upton]I’d watch the memory use of the app over time and see if it rises before it crashes

[/quote]
It seems to be a Memory-leak as you said. :confused: 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!!!