If you’re dealing with a situation in your code where two classes need to reference each other, then you could be leaking memory if you haven’t taken steps to prevent that.

Let’s look at this with a simple example.

• Create a new Xojo project and add two new classes to it, ClassA and ClassB.
• Add a ClassBReference As ClassB property to ClassA.
• Add a ClassAReference As ClassA property to ClassB.
• Add a Constructor to ClassB using the following signature:

Constructor(reference As ClassA)

And add this line of code to the method:

Me.ClassAReference = reference

Next, add the Destructor method to both classes and type “Break” as the only line of code for them. This will allow us to see if they leak memory or not. For example, if when debugging the example project the Debugger doesn’t reach the Break lines, that would mean that the Destructor has not been called and, thus, the objects are not released from memory. They are leaking!

• Now add the Opening event handler to Window1 and type these lines into it:

CreateReferences
Break

As you can see, it calls the CreateReferences method and then breaks into the debugger.

• Now add the CreateReferences method to Window1 and type these lines of code in the associated Code Editor:

Var ca As New ClassA
Var cb As New ClassB(ca)

ca.ClassBReference = cb

Now it’s clear what is going on here: ClassB instance is keeping a “hard” reference to ClassA (via the ca instance), and then the ca reference is keeping a “hard” reference to the classB instance cb.

Run the project. Is the debugger stopping in the Break lines of ClassA and ClassB Destructors? Nope. They are leaking because they are using hard cross-references with each other.

You can see it more clearly when accessing Global > Runtime > Contents in the Debugger panel. Both objects are still alive:

WeakRef to the Rescue!

But let’s say that your app design needs to keep these references. How do we solve this situation? The answer is using weak references instead of hard references, and the Xojo language has a class for it: WeakRef.

Let’s change ClassA and ClassB properties so their type is a WeakRef. Setting their definition as:

ClassBReference As WeakRef
ClassAReference As WeakRef

And let’s change the ClassB Constructor code so it creates a new WeakRef instance from the received object, instead of assigning it directly to the property.

ClassAReference = New WeakRef(reference)

And let’s change the code in the CreateReferences method to:

Var ca As New ClassA
Var cb As New Classb(ca)

ca.ClassBReference = New WeakRef(cb)

Run the example project again. Now you will see that the Debugger stops at the “Break” lines for each Class Destructor. Which means they are correctly released from memory. Problem solved!

WeakRef Memory Care

When using WeakRef objects through the code, keep in mind that accessing the real object they are referencing is done through the WeakRef.Value property in addition to Cast to the original Class.

To see it more clearly, add the “SayHello” method to ClassB and type this line of code into the associated code editor:

MessageBox("Hi From ClassB Instance")

Then, select the CreateReferences method from Window1 and add the following line of code at the end:

ClassB(ca.ClassBReference.Value).SayHello

First, we are accessing the ClassBRefence property from the ca instance; that gives us access to the WeakRef instance property, so we need to access its Value property in order to get access to the real object instance we are really interested (a ClassB instance).

But, because the Value property returns a generic Object, we need to Cast it to the class instance we expect (and should know) that is referenced by the Value property; in this case a “ClassB” instance. To do this, we are using the Cast expression:

ClassB(ca.ClassBReference.Value)

Next, and because we did Cast it to ClassB, we can continue using the dot notation in order to call any of the methods / properties exposed by ClassB, in this case the “SayHello” method.

Run the app again and now the ClassB instance referenced by the ClassA instance is displaying the MessageBox.

In addition, when accessing a hard referenced object in your class properties it can be good to do a sanity check like:

If ca.ClassBReference <> Nil Then
  ca.ClassBReference.SayHello
End If

But when using WeakRefs you need to do a double check. First against the WeakRef itself, because it can be a Nil object! And second, against the object referenced by the WeakRef itself. So the previous check will read now:

If ca.ClassBReference <> Nil And ca.ClassBReference.Value <> Nil then
  ClassB(ClassBReference.Value).SayHello
End If

Clearing It!

All in all, cross-referencing objects among class instances is probably not the best design, but sometimes it is needed. In case your app design needs to follow such a path, take care and use weak references (with Xojo’s WeakRef class) instead of hard references.

Keep it in memory (or not, if it is leaking)… and happy coding with Xojo!

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

However, sometimes the combination can simply reach unstable situations by the very nature of our applications and here is where failures can arise in memory management. Fortunately, we can keep this under control with the help of the WeakRef class.

This is, in fact, what happened to me recently while implementing a new feature in Snippery my productivity application where one of those unlikely but possible cases one of the objects left in an unstable state. What does this mean? The referenced Control object stored in a property was not marked as nil once it was out of scope because its containing window was closed, so it was simply unsafe (an dangerous!) to check or access its properties and methods through a simple verification of the type:

if miPropiedad <> nil then

Despite the object referenced through the property would have been released, this condition will execute the code inside the block resulting in a unexpectedly exit from the app! In fact inspecting the object via Xojo’s debugger shows that the reference is still there but it inner structure is void.

So executing the previous code will bring a beautiful error message from OS X:

EXC_BAD_ACCESS (SIGSEGV)

That is an attempt to access a memory vector where we expected to find a data structure that is not there anymore.

I have to say that after further research on the subject I have found that this kind of error does not always occur and that it may depend on the type of object that we maintain the reference to, or even the property we want to access, or the method we try to call when the objects is in this “unstable” state. In the best of the cases, simply nothing happens. In the worst case, your application will suffer an unexpected exit you will not be able to trap using the Try … Catch block or exception handling mechanism offered by the Xojo language.

If you want to see for yourself what I’m talking about, you can download the example application that reproduces this kind of problem related with memory management.

WeakRef to the rescue!

How can we solve these kinds of situations? Easy! The WeakRef class allows code to maintain weak references to objects. When you wrap the object you’re interested in an instance of the class WeakRef, we will ensure that such reference is released (and thus becomes nil) through proper memory management. So, problem solved! From this point on we can perform and trust a conditional test of the reference against ‘nil’ before trying to access any of the properties of the object itself.

In the case of our sample application, we can fix the problem with the following changes:

1. We define the property SourceControl Worker class to be of the WeakRef Data Type
2. We make the following changes to Worker class constructor (where the referenced Control instance is now wrapped into a WeakRef instance):

sourceControl = new weakref( c )

3. We modify the conditional block of code for the Worker method to:

if sourceControl.Value <> nil then
  textArea(sourceControl).SelLength = 0
  textArea(sourceControl).Text = “This is a test”
end if

Note that in this case we Cast SourceControl to TextArea, so  we can work with the properties and methods of the control that we know are actually a control of TextArea type.

Make the changes, run the app again and you’ll notice that this time the app will continue running without errors once all the windows are closed.

You can watch the video (in Spanish only) that talks you though this example.

Javier Rodríguez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has used Xojo since 1998. He is in charge of AprendeXojo.com and the developer behind the GuancheMOS plug-in for Xojo Developers and the Snippery app among others.

*Read this post in Spanish.

Client apps for the desktop and mobile are pretty straight-forward in terms of both determining how much memory they will use and testing the app since only one person uses the app at a time.  Even if the app does run out of memory, it only affects one user. When building web apps, web services or really just about any app that’s going to run on a server in the cloud or otherwise, the risk is far greater. If the app crashes, every user is potentially affected.  Determining the memory needed is more difficult as well. The primary reason is that you will have potentially many users accessing the app at the same time and each using varying amounts of memory. The situation is made worse by the fact that most modern operating systems no longer manage memory behind the scenes in the same simplistic way they once did.

Getting on TOP of It

The most common server operating system is of course Linux and the tool of choice for knowing how your apps are behaving is the UNIX app know as TOP. TOP provides a lot of interesting though potentially confusing and even misleading information.

Here TOP is showing us information about the server in general such as the average load, the number of tasks, how busy the CPU is, how much memory the server has and how much is available, etc. Below that, TOP breaks down information about each process, some of which are apps while others (in this case) are connections to an app. The first three processes in this case are web apps.  The most important columns are VIRT, RES and %CPU.

VIRT (Virtual Memory) indicates how much virtual memory the app is using for data. For example, the EEWeb-Dev app is using 81504K (81.5Mb). This value will go up and down as your app uses more or less memory for data.

RES (Resident Memory) indicates phyiscal memory used by the app/process.

%CPU indicates how much of the CPU the app is using at this moment. It’s not unusual for a web app to occasionally use a lot of CPU and then a moment later use very little.

Note: Different Linux distributions display VIRT and RES differently. CentOS, for example, displays these values  in K unless there’s not enough room. So 81504 is 81.5 Megabytes. 41m is 41 Megabytes. To determine how much memory your app is using, you’d add VIRT and RES together.

Considering all the information available, you’d think it would be easy enough to determine how much memory your app is using. After all, TOP shows you how much memory is free. Isn’t that enough? Unfortunately, it’s not that simple. You might think that as soon as your app stops using memory (for a user connection for example) that it’s instantly free and available for other apps to use. Nothing could be further from the truth. The OS has a lot of priorities only one of which is dealing with memory that has suddenly become available. Like you, it prioritizes based upon need. If there’s plenty of free memory already, it may not bother cleaning up memory freed by your apps for some time. If another app suddenly needs a lot of memory and the free memory won’t suffice, the OS will immediately kick in and collect all the freed memory from various apps. However, if nothing puts pressure on the OS to do this, it could be anywhere from a few seconds to more than an hour before the OS cleans memory up. This means simply monitoring TOP for a few minutes isn’t going to be enough.

If you’re using Xojo Cloud you don’t have to worry about any of this. Starting with Xojo 2018 Release 1, Xojo has built-in server statistics that you can easily display to show CPU, memory, network and disk statistics for the entire server and individual apps.

Leaking Memory

If you have the kind of app that gets used only during specific hours, you could take a look at memory usage before everyone starts using it, again when everyone is working and finally an hour after they finish. Unless your app is designed to hold on to information in memory even after users have shut down for the day, the memory available should have returned to approximately what they were when you started. If your app is still using a lot of memory long after all your users have quit, you’ve probably got a memory leak.

A memory leak occurs when memory is allocated for something but then never released. If a leaking function is called over and over, the amount of memory being used continues to climb potentially until there’s none left and the application crashes. The most common reason for this is your code has created some kind of data object and stored a reference to it somewhere but the reference never goes out of scope. Say you’re storing the reference in some global part of your application code. Unless something clears the reference, the memory will continue to be used indefinitely.

How Much Memory do I Need?

If your app or apps are behaving themselves, the memory used goes up and comes back down later on. In that case, the question is, how much total memory do you really need? In computing, we are used to very black and white answers. In this case, the answer is not so satisfying. If your server runs out of memory, the client is going to get disconnected and ideally, provided an appropriate error message. Web apps made in Xojo for example, display such a message to the end user indicating that an Out of Memory Exception has occurred. In this case, when a user reports this to you, you’ll need to determine if your app is leaking memory or simply needs more of it. Now, you’re probably thinking, “Is there any way for my app to know that it’s about to run out of memory?” Not really. It’s using memory from a pool available to all apps. Even if your app could monitor how much memory is free, it doesn’t know if other apps or the OS itself are about to make more available. Once the Out of Memory Exception (or the equivalent error message in the language you are using) occurs, there’s usually not enough memory left to confidentially do anything but crash.

The good news is that there’s a relatively painless remedy. Memory is cheap. If you have your own server, buying more RAM is an inexpensive solution. It’s probably worth buying a lot more than you think you will need. It’s the lowest cost insurance policy you will ever buy. If you are using a cloud hosting solution (like Xojo Cloud for example), then getting more memory involves upgrading your server. In the case of Xojo Cloud and most cloud-based solutions, this is very simple, usually involving shutting down the server for a few minutes then bringing it back up again with more memory allocated.

The Solution: Trial and Error

The best preemptive measure is to find your app’s memory high-water mark. Monitor the memory when usage peaks, ideally over several hours, to see how close you are getting to running out of memory. This will at least give you some rough sense for your situation allowing you to remedy it before your users crash the app and cause a lot of headaches for each other and for you.

Determining how much memory your app needs, at least for most people, is a question of trial and error. This is because operating systems don’t free up memory instantly making it difficult to judge how much memory the app is really using at any given moment. The good news is that despite this, adding more RAM to a server is cheap and easy.