I have a situation where I go to Run a Desktop app and the compilation process hangs until the system runs out of memory. Details below. I am wondering how do I go about debugging this? Is there any way to get xojo to display more detail about what it’s doing during the build?
Computer: Mac M1 Pro laptop w/ 32GB RAM
Xojo: 2022 Release 1.1
I click Run and the build pop-up is displayed. It gets to “compiling module 91/91 (mod_name)” and then hangs with the Apple system spinning cursor (rainbow spinning cursor). Eventually the system displays the Force Quit window and informs me that it’s out of memory and helpfully lists the running applications, requesting me to kill one or more. xojo is taking about 120 GB and that number is increasing, and xojo is “not responding”.
The code I was changing is completely unrelated to the mod_name listed in the build pop-up, and pretty minor. I suspect that it’s something hung and gobbling memory after that phase is over but have no idea what it could be or how to figure it out.
Has anyone seen anything like this? Or have some secret flag I can toggle to get more diagnostic information out of the build process?
The same failure occurs when running remotely on another platform (windows) or when building executables for any platform. The building pop-up window disappears when building (as opposed to Running) but then xojo hangs with the same growing memory use problem.
This failure only occurs with one desktop application that I was modifying (it would compile - I added some code - it now hangs up xojo during the compile process for either running in the debugger or to build a stand-alone executable). I can load and run other projects. And I can load and run an earlier version of this project. When it fails, I get no syntax errors. The failure (and out of control memory consumption) seems to occur during some step of compilation after it has finished compiling modules.
I guess the desktop application is moderately large - the xojo project is about 27 MB.
First, what version of macOS? There were a few early versions of 11 that caused this not just with Xojo but others.
Otherwise, I’m guessing that the size of your project is caused by pictures and/or movies that were dragged into your project. You could try loading those at runtime instead.
The only other thing I can think of off the top of my head is method size. Make sure that you don’t have any overly long methods in that last item that it’s trying to compile. If you do, break it up into smaller parts.
Regarding size. I’m honestly not sure why it’s so big. The only images in it are the App icons and some graphics used for buttons. Raw total of those files is less than 1 MB. There doesn’t seem to be that much code but there are 12 windows and a large number of objects and the various parts, created over the years, use both APIs.
The last method isn’t big at all. If I remove it from the project then the same failure occurs after whatever the new last module is. I think the module is getting compiled, but whatever xojo does after that is hanging. I say this because if I try to build an executable (as opposed to Running a debug version) the pop-up dialog box that xojo uses to display build progress goes away before xojo hangs up with the spinning color cursor of death.
What if you try to start with the project without this added code and add pieces of the new code, try to compile, and add another piece (etc.) until you find the issue?
Not only would you know where it breaks (then find a possible workaround), but it would also benefit Xojo (and us) by knowing what’s the problem you’re getting.
The project is so large because the app and file icons are saved very inefficiently. I add the icons now after building which makes saving the project much faster.
As Arnaud said: comment out code until the memory leak goes away.
Thank you all for the helpful information. I am trying to back out changes, one-by-one, to see if I can find the trigger. I will report back.
Beatrix ~ How do you structure your projects so icons can be added later? Specifically I mean how are the files stored as part of the project delivered to customers? I’m a hardware guy who uses xojo to build supporting applications and not a software developer.
I imagine my use of xojo is probably pretty simple compared to you all and I treat it mostly as a press-the-button to get a binary kinda thing.
I ran into something like this many years ago, it turned out that I had too many methods in a single module, and possibly also that some of the methods were quite large. I split them up into more modules, and the problem went away.
use IconComposer2x (Releases · lemonmojo/IconComposer2x · GitHub) to put all files into an icns file. The file icons need to have the same name as the file type. The app file needs to have the name “App.icns”.
do a copy file script step to copy the files into the resources folder of your app:
@John_McKernon ~ Maybe you’re on the right track. I got the app to compile with the change below. In my case it might be too many properties. Do you (or anyone) have any idea what the limits are? My application main window has the most methods (82) and properties (50). This is where the main logic of the program resides.
The application controls a piece of hardware. It has a main window which can open sub windows for various activities. Right now the program can only work with one device at a time and the windows are implicit and there are hard references between them (a sub window may access something in the main window). I wanted to modify the program so it can communicate with several devices at once, each with their own main window which can open sub-windows related to that specific device. To do so I wanted change all windows from implicitly created to having to be created with a set of properties in the main window that would point to the sub windows it can open. Then it would pass a reference to itself into their constructor so they can reference it when necessary, associating themselves with the correct device.
What doesn’t work: I add a single property of type SubWindow to MainWindow. I create and hide a SubWindow during the initialization of MainWindow using New. Code in MainWindow calls Show on the property in some event or method when it wants to open the sub window.
What works. Moving the declaration of the sub window property out of the MainWindow property section into the specific event or method that wants to open the sub window. I also moved the creation of the window using New to the same event or method immediately preceding the Show.
So the difference is the location of a property and when New is called. Since I really want the sub window property to be global to all main window methods and events, my work-around doesn’t cut it.
I tried to create a test program to duplicate the failure in a simple way that could be shared but cannot make the failure occur. I even added some various other objects to it from the original project but gave up because it would be a huge process to add them all. This leads me to wonder if as John suggests I’m exceeding some xojo limit. Does anyone know if xojo a) identifies limits anywhere and b) has any way to increase them if they exist?
A twist. The application is many years old and is a mixture of API 1 and 2. I’ve resisted the effort of moving it to 2 but maybe I should spend the time.
In the failing case the New for the sub window property was in the main window’s Open event. For historical reasons I creat objects in this event. But it calls a method to initialize the window controls. When I moved the New for the sub window property to that method the application compiles and runs. When it’s in the calling Open the compilation hangs and consumes endless memory.
The method isn’t actually called during compilation. Are you sure that the your app wasn’t running and it was that which was hanging? If the window opens another instance of itself in the Open event, it’ll just keep recursively opening windows, probably forever, without showing anything.
I’m pretty sure. It hangs when building a binary too. And when “Running” a debug session the xojo popup displaying build process is still displayed over the IDE and there are no other processes (such as the debug version of the program) started on the Mac.
Also the main window isn’t creating a version of itself. It’s creating a sub window of another kind. I don’t think this is a run-time issue (although I understand what you’re saying and see how that could cause a similar looking issue).
I do appreciate you all taking the time to think about my problem. Very much.
I have 2 projects that will not compile in the latest versions. Both were created with earlier versions and will compile in 2021R3.1. 1 was small enough that I was able to recreate it in 2022R1 and will compile, the other I’m simply using the older version. There is a private case in issues about this.
The best is you send a copy of this project to Xojo and they can hopefully reproduce the issue and fix it. If there‘s something wrong with your project (in general) the IDE should detect and report this.
