2024r4.1 and Lifeboat (crash)

I upgraded from Xojo 2024r4 to Xojo 2024r4.1 and the app I had started to “crash” and I don’t get any message about what’s going on.
I recompiled on the one I had before Xojo 2024r4 and the same thing happened to me, I had to end up doing a compilation on Xojo 2023r4 which solved the problem for me.

I suppose it could be some issue with Lifeboat (Build 202), the strange thing is that I have other apps that I was able to update and they didn’t “crash”, I see that the new version of Xojo talks about “Explicit TLS v1.3 support for SSLSocket” could that have something to do with it?

I’ve already spoken to @Tim_Parnell but he doesn’t realize what it could be. I also wrote to @Ricardo_Cruz and I’d like to take this opportunity to add @AlbertoD and @Javier_Menendez who always give me a hand in Spanish and the rest of the community in case anyone has had the same problem.

Thank you very much!


He actualizado de Xojo 2024r4 a Xojo 2024r4.1 y la aplicación que tenia comenzó a “caer” y no obtengo ningún mensaje de lo que ocurre.
Volví a compilar en la que tenia antes Xojo 2024r4 y también me sucedió lo mismo, tuve que terminar realizando una compilación en Xojo 2023r4 lo cual me solucionó el problema.

Supongo que puede ser algún tema con Lifeboat (Build 202), lo extraño es que tengo otras aplicaciones que pude actualizar y no se “cayeron”, veo que la nueva versión de Xojo habla de “Explicit TLS v1.3 support for SSLSocket” tendrá algo que ver?

Ya hable con @Tim_Parnell pero no se da cuenta que pueda ser, también le escribi a @Ricardo_Cruz y aprovecho a sumar a @AlbertoD y @Javier_Menendez que siempre me dan una mano en Español y resto de la comunidad por si a alguno le ha pasado lo mismo.

Desde ya muchas gracias!

You need to define what is a “crash”.
If your app was working with Xojo2024r4, then it didn’t work correctly with 2024r41, went back to 2024r4 and still didn’t work and you have to move back to 2023r4, that is very weird. Looks like something got corrupted at the server or depending on the “crash” maybe a cache issue.

We have a couple of internal apps that we use every day, compiled with 2024r4 and now 2024r41 without any “crash”. Several client projects are running 2024r41 too without any reported crash.

What server type are you using?


Necesitas indicarnos a qué te refieres con ‘comenzó a “caer”’.
Si el app funcionaba bien con 2024r4, empezó con problemas con 2024r41, regresaste a 2024r4 también con problemas y tuviste que usar 2023r4 para que funcionara, es algo muy raro. Tal vez algún archivo dañado en el servidor a la hora de subir los archivos, o dependiendo del “caer” algún archivo en cache.

Tenemos un par de aplicaciones que usamos todos los días corriendo en 2024r41 sin problemas, varios clientes también están en 2024r41 y no han reportado problemas.

¿Qué tipo de servidor usas?

1 Like

How many instances of the app are running on your server?
I had a very similar problem, the app was crashing and restarting every 2-3 minutes when I was running 2 instances of the app on the same server.
As soon as I went back to running only one instance, the app didn’t crash anymore.

1 Like

Well, something seems going on. If you guys can produce a sample able to work at 4.0 and crashing in 4.1 open an issue report ASAP. And getting some infos from the logs, if some is found, may help. Maybe some clue are written into /var/log/syslog or /var/log/messages or /var/log/kern.log at the crash time.

1 Like

Just to be super de duper clear, when you roll back to a previous version of Xojo and the problem goes away, the problem is not Lifeboat.

2024r4 and the .1 release are not approved for my clients to use for Web because of the issue Jeremie reported in previously. You may choose to adopt a similar policy. We’ll see how 2025 goes.

2 Likes

@AlbertoD, the “started to fall” refers to the fact that from one moment to another the application no longer appears, I had to stop it and start it again with lifeboat, I would have to see after leaving it for several minutes if it ends up showing something (I will do it and I will let you know).
I have already emptied the Cache with the option that Lifeboat brings, but it could be something like what you indicate of a damaged file in that specific folder of the app, if I am not mistaken Lifeboat does not upload the entire application but only detects the update, perhaps there is some detail there, I will try first to delete the application and then upload it again.
I made another compilation of the same code and uploaded it to another domain of lifeboat and for now it does not “fall” so it could be what you indicate.

@Jeremie_L, for now I am only running 1 instance in Lifeboat because my server only has 1 processor.
Lifeboat is running Debian 11.

@Tim_Parnell, correct, with 2023r4 it doesn’t “crash” but it was working fine with 2024r4, that’s why I’m surprised, and also because of what I mentioned above, when I uploaded it to another domain (same server and lifeboat) it doesn’t seem to crash.

Well, it’s a pretty strange situation, at least by downgrading the version I know the problem is solved, but it would be good to know what’s going on, because the truth is that Lifeboat is an excellent tool and I depend on it for deployment, so as long as Xojo presents me with some problem I’ll have to adjust.

Thanks to everyone, it’s a great community!


@AlbertoD, el comenzó a “caer” se refiere a que de un momento a otro la aplicación no se muestra más, he tenido que detenerla y arrancarla de nuevo con el lifeboat, tendria que ver luego de dejarlo varios minutos si termina presentando algo (lo voy a hacer y les aviso).
Ya vacie el Cache con la opcion que trae el Lifeboat, pero puede ser algo como lo que indicas de algun archivo dañado en esa carpeta puntual de la app, si no estoy equivocado el Lifeboat no sube toda la aplicacion sino que detecta solo la actualizacion, quizas ahi hay algun detalle, probare primero eliminar la aplicacion y luego vilver a subirla.
Hice otra compilada del mismo codigo y lo subi a otro dominio del lifeboat y por ahora no se “cae” asi que podria ser eso que indicas.

@Jeremie_L, por ahora solo estoy corriendo 1 instancia en el Lifeboat porque mi server solo tiene 1 procesador.
El lifeboat esta corriendo Debian 11.

@Tim_Parnell, correcto con la 2023r4 no se “cae” pero venia funcionando bien con la 2024r4 por eso me extraña, ademas por lo que les comentaba arriba que realice otra subida a otro dominio (mismo server y lifeboat) parece no trancarse.

Bueno es una situación bastante rara, por lo menos bajando la versión se que se soluciona el problema, pero seria bueno saber que pasa, porque la verdad Lifeboat es una excelente herramienta y dependo de ella para el despliegue asi que mientras Xojo me presente algun problema debere ajustarme.

Gracias a todos, es una gran comunidad!.

It looks like you are not getting a crash. This is different as what Jeremie reported.
As Tim said, not related to Lifeboat.

Something related to the specific server then.

We have several one instance applications and at least one installation with 4 instances with no reported problems.

@Tim_Parnell , just in case, in Lifeboat under “Web Apps” is there a way to delete all the content of the “Live App Files” so that the “Upload app” is complete?


@Tim_Parnell , por las dudas, en Lifeboat en “Web Apps” hay forma de eliminar todo el contenido del “Live App Files” para que el “Upload app” sea completo?

Available memory?
Newer version of the same app, working ok, consumes a bit more and :boom:
Newer version leaks and :boom: ?

Lifeboat hashes all the files to see whether or not they need to be updated. You’re blaming Lifeboat for a Xojo problem again. Xojo isn’t changing any bits .

The only way to clear the server files would be to stop and delete the app. Lifeboat uploads while your app is running, so it doesn’t clear the live files.

Though, it does skip the hash step to save time with more than 150+ files to upload. You could leverage that if you really want to.

2 Likes

@Rick_Araujo ,
The server is the same, I just created one more domain in the lifeboat to upload another compilation of the same code, it may have leaks but they would be the same as in the working copy, I am more inclined to think of some “garbage” that would remain, that is why I consulted Tim about how to delete all the content (not the creation of the app) before uploading again.


El servidor es el mismo solo creo un dominio más en el lifeboat para subir otra compilada del mismo código, puede tener fugas pero serian las mismas que en la copia que funciona, me inclino más a alguna “basura” que quedara, por eso le consultaba a Tim sobre como borrar todo el contenido (no la creación de la app) antes de volver a subir.

Ok, understood Tim, thanks a lot!


Bien, entendido Tim, muchas gracias!

This does not apply here, as:

so Mauricio is running the same code build with Xojo2024r41 on the same server without problems. The only difference reported is: a different domain.

1 Like

For a moment I thought it was another server too.

1 Like

The message I end up receiving in the browser is:
El mensaje que termino recibiendo en el navegador (luego de un buen rato) es:

504 Gateway Time-out


nginx/1.18.0

Your app, dead or alive, is not responding in the time allotted for it.

When the app is dead it causes a 502 because there’s nothing upstream. A 504 timeout tells us that the application is at least running.

504 is a new error that I have never seen a Xojo Web app cause previously.

Thinking further on this: It would seem this may be the first ever time the constant sprinkling of “upstream timeout” in the nginx access.log has finally been a fatal error for someone. I have been seeing this message throughout Web 2.0 app logs since the dawn of Web 2.0, but it has previously never been a fatal error and has never had an effect noticed by an end-user.

In theory, It could start a connection and freeze. Then a 504. If frozen (or terminated) and not accepting more connections a 502 series would start.

1 Like

Testing, it is the 2024r4 and 2024r4.1 versions that end up giving me problems, while the 2024r3 or 2023r4 versions that are compiled do NOT “crash”.
Could it be in the HandleURL but without causing an “UnhandleException”? (since I have nothing in the log), or in some use of URLConnection that is made later? @Ricardo_Cruz I will continue investigating.

Haciendo pruebas, son las versiones 2024r4 y 2024r4.1 las que me terminan dando problemas, mientras que las 2024r3 o 2023r4 la compilada NO “cae”.
Podria estar en el HandleURL pero sin provocar un “UnhandleException” ? (ya que no tengo nada en la bitacora), o en algun uso de URLConnection que se haga luego? @Ricardo_Cruz seguiré investigando.

If Xojo would use Xojo for their own web site, they would have discovered this themselves.