I have a small testserver at home, Ubuntu 12.04.3 LTS, x86_64, and I cannot reproduce that error, see yourself here
Hi Oliver. Very interesting. Are you using the exact code I uploaded in my bug report? I suspect it’s some nuance in my code that I’m just blindly ignoring. Although even if it is my code, I would hope that a try/catch would trap it, but it doesn’t.
I have no doubt that Xojo standalone web apps run on Ubuntu 12.04; I’ve done it myself before. But this particular app is crashing without a trace, and I’d really like to nail down why so I can change what I’m coding and/or change the server configuration so it doesn’t happen.
If you have a chance, maybe you could pull down the code from bug report 30797 and run that.
It’s also worth noting that I’m running on a 32-bit instance. I started off on 64-bit, but moved just in case it was the 64-bit that was causing the problem.
Thanks!
No, I quickly wrote my own test (download here)
I downloaded your feedback project, but it is not completely stripped down and I have no time to study it now. So you may want to do it the other way round: my example contains just a minimum of code, build it and run it on your own server. It is what runs on my own homeserver right now.
So there is one thing that sticks out at me… and that’s how you are putting the script together in the Constructor (which you are not in the code that works). Have you tried checking:
A. Using System.DebugLog to output the actual script that’s being pushed in
B. Making sure that you have consistent line endings? For instance, you might want to add this to the end of your Constructor:
myCodeLines = ReplaceLineEndings(myCodeLines,EndOfLine)C. Check the encoding of the VariableDefs items vs CodeLines. If they’re different, that might be an issue (although I’m not 100% sure about that)
Oh and… App.Daemonize in the App.Open event… What is it that you are trying to accomplish with that?
@Greg: all good suggestions, and I will try them. As far as Daemonize goes, I picked that up from a post by Paul L on the Xojo blog:
http://www.realsoftwareblog.com/2012/03/daemonize-your-standalone-web.html
Right. I’m assuming that you are doing this so you can start the app and then exit the terminal without killing the app. I suggest that you comment that out and try this:
nohup MyApplication &App.Daemonize is handled differently on Linux and OS X because of the way processes spawn.
Oh yeah, and try calling XojoScript.PreCompile with the different optimization levels. It certainly could be a bug in the optimizer.
STOP THE PRESSES!
I think this is a memory issue with my Linux server instance and Xojo.
I had been running these tests on an Amazon t1.micro instance, which I often use for testing this kind of thing. It usually works fine for PHP/MySQL kinds of projects, and I’ve run some Xojo standalone web apps on t1.micros as well.
But just for the heck of it, I spun up an m1.medium instance (3.75 GiB of memory vs the t1’s .615 GiB) and everything worked like a charm! No errors, no crashing.
So my questions are:
-
Is there some way I can know this in advance? Some kind of instrumentation or trap I can put into my Xojo app to detect a low-memory problem and gracefully abort, rather than just crashing?
-
I wonder why this particular app is having problems with memory; it’s a very small one-page app. I’ve done other, multi-page apps with webListboxes etc. before, using this same instance configuration. So perhaps I’m doing something bad with XojoScript that is triggering a particular edge case in the engine?
In any event, this is some real progress, and I will now proceed to try to figure out how much, exactly, memory this thing is using and why.
@Oliver: thanks for building that test app. I tried it on my server, and it CRASHES in the same way as mine does. However, it does NOT crash on an Amazon instance with larger memory.
So now I’m even more convinced that it’s a memory issue with XojoScript.
@Greg: I did try removing daemonize, no difference in behavior. And the debug output for the script text looks fine.
@Greg: just tried it again on the t1.micro instance with all 3 different optimization levels; no difference. Precompile returned TRUE in each case, but then when it hit the Run method it crashed the same as before.
So now I’m not sure if memory really is the problem or not. Could someone please check my math here?
Using “top” while running the app shows 609452k total, 580244k used. So not much headroom left, but still 29208k.
I put in some Runtime.MemoryUsed debug outputs right before the place where the app crashes, and it shows 845624 bytes in use. By my calculations, that still leaves 29,063,368 bytes free, or around 28MB.
Is it possible that calling XojoScript.Run will try to malloc 28MB (equal to 34 times the app footprint before the call) ? I can’t imagine that. Nonetheless, it definitely runs fine on a larger server. But I don’t understand why.
Perhaps it’s something else about the t1.micro configuration? Once upon a time before the Internet, I used to write the occasional Unix device driver, but my knowledge of present-day Linux is sadly lacking. Can anyone enlighten me on what might be going on here as far as configurations go?
I would raise an incident with AWS, but I predict they’d just look at my use of Xojo and scratch their heads, since they’re all Java/PHP/Ruby/node.js people.
Found a solution that seems to work. This only appeared when running the app on Ubuntu (20.04 in this case) in a docker container on MacOS - fine on Windows docker, fine in Ubuntu VM. As Greg indicated above precompiling the Xojo script corrected the issue (both Low and High options seemed to work fine).