I have collection of WebApps that work in conjunction on the same project. Each of them worked so well under Xojo R3.1, and (4) out of (5) of the apps migrated well thru Xojo R4.2, and even R5.0 (current release). However, one app is stuck at R3.1 It runs great under 4.2 and 5.0 in the IDE, but builds for those releases (just for this one app) never finish starting up fully and then go into a repeating loop of crashing.
I’m returning True in the App.UnhandledException just to keep it alive long enough to get some data. But the only sable and deployable version is under R3.1 (and below).
The app in question uses a ton of WebContainer controls, which is the only difference I can tell between it and the other apps in it’s family.
Does any of this look familiar to anyone? Without any failures in the IDE it’s so hard to know why it’s failing in production…
My only failures to build are when I try Aggressive Optimisation Level (I default to Moderate now), but I assume you’ve tried this. But reading again, it looks like you can actually build it, but not successfully run it.
One good way of finding bugs is to build it for another platform eg Windows or Linux, as often bugs that don’t manifest in one OS will appear in another.
My only remotely similar experience recently was with the GraffitiSuite Demo freezing around 24 hours after deployment when built with 2024r4.x and 2025r1.x. And, of course, the service appeared to be running to the system so it would just hang in that dead state rather than being restarted.
I still don’t know what was causing it or what fixed it, but it’s been solid for a few days now after setting up other locations with the same build to see if it was just the one VPS acting up.
Are you logging anything from App.UnhandledException?
If you change the main Webpage to a “hello world” does it display correctly?
You could try adding Sentry to your project, adding Breadcrumbs (see demo projects from the Sentry repo) and logging informational exceptions to Sentry to pinpoint the exact moment it fails.
If you need help with that feel free to ask here or PM me.
Let’s explore that a little. Are you truly talking about “crashing” or are you talking about the app closing due to an unhandled exception. They’re different, and it matters to this discussion.
Also, you’re running in the IDE, but on what platform? Is it the same as the environment where you’re trying to run the built app?
For instance, if the runtime environment is Linux, you should be able to glean some information from the system log at the moment when the app crashes.
Ok, that helps a lot. Xojo Cloud is a special beast on its own, but we can work with that.
First things first… Do you have any other apps running on your Xojo Cloud server? If so, are you sure that you’re not just running out of RAM? Newer versions of the framework sometimes have higher memory and cpu requirements than previous ones. You should be able to tell by using the Xojo Cloud monitoring that’s built into the IDE.
I did a quick review of the 2024r4 release notes. I don’t see anything that should have outright caused an app to suddenly start crashing on startup. I think your best bet is to get someone at Xojo to go look at the system log and see what the error message is.
@Greg_O thanks! For sure the RAM isn’t an issue, and the other sibbling apps on same instance are all running fantastically. It’s just this oooooone app. I’m going to see if the cloud team can fetch logs, and I’m going to rem-out some of the offending apps startup procedures and see if I can pare it back (pair it back?) to a point where it works, and then reintroduce segments till I find the issue. It’s hard because it means mutiple deply/test/change/re-deploy loops. When I find the smoking gun I will post it here for sure!
@Greg_O may be very well on to something with the RAM hypothesis. The other apps are running fine, but each one grabs some RAM. If the memory footprint of the app compiled with newer Xojo releases is larger than it was with R3.1, not necessariliy a lot larger, then the app may fail to start properly because the initial memory requirements exceed the remaining available RAM. So, one thing to try would be to stop the other apps, and then deploy and start this one (compiled with one of the newer Xojo versions). If it runs, then possibly you are short of RAM. You can then restart the other applications one by one. Chances are that the last one to be restarted will also fail in a similar manner - unless we are in a situation similar to loading drivers in high memory in PC-XT and MS-DOS 3.x era (older folks here may remember tweaking the initialisation steps to cram as many drivers in high memory as possible on machines with a huge 1024K of total RAM, to retain as much of the standard 640k for apps. The loading sequence of drivers in high memory mattered. But I digress). You would have a very good indication that the server is insufficiently provisioned with RAM.
It is probably somewhat easier to perform this test than to perform surgery on the code as you are planning to do.
I’m peeling the onion and bent on getting to the bottom of it. The app is a dashboard, and it creates ~50 to 100 “tiles” based on active records being worked during a given day. When I reduce the recordset to 3-4 records it miraculously starts working. Then I add a few more, and it keeps working. But when a larger collection of records (one that versions compiled in previous versions of Xojo can handle just fine) is present it dies. I’m going to keep on digging…
Intentionally about 15 secs. The app stagger-starts a few services, e.g., the dbase connectivity is “turned on” 20 secs after app starts, giving time for dbase’s to come online after a server reboot. The session normally takes about 10 secs to stage it’s own services, and all these times seem to behave as expected. Once I reduced the containers down from 80 to 2 it all worked fine. Which leads me to continue my investigation - my next plan it to disable the autonomous functions within each container dig deeper and deeper…
