WebContainers: WebDialogs, WebControls don't get always released - Memory Leaks?

Targets Web
1

While trying Xojo Web I’ve stumbled upon various WebControls that remain in Memory forever (Memory Leaks…?).
Likely related to the fact that I’m using WebContainer’s, or that those never-released Controls are within WebContainers.

I’ve tried to make sure that all AddHandler have a RemoveHandler.
And when in one example container I’ve been using a WebDataSource which is within the Parent of the ListBox that gets the WebDataSource, it gets nil-ed out when being closed (not to get a circular reference).

While having placed Issue 76039 I’m still curious…

  • is this my mistake? What have I done wrong so that those Containers/Controls/Dialogs don’t get released?
  • is this really yet another Memory/Framework Issue in the Xojo Web Framework?
  • but most importantly… who finds a workaround to get these Controls released?
    I’ve tried various things in .Close and Destructor’s in this example - without success :frowning:

If you’d like to try, then get the example project from the linked Issue 76039.

While the Login Page is showing, the expected output of Objects in the Xojo Runtime are:

  • LoginPage: 1
  • WebButton: 1
  • WebLabel: 1

You then can “Login”, and use the ToolBar to show some content.

  • Container Main is shown by default (empty Listbox)
  • Container One: you can add/delete items shown in the Listbox
  • Container Two: uses a WebDataSource (which is the container itself) and you can add/delete items shown in the Listbox

Once you logout, all Containers should have been closed and no longer be in memory.
So after clicking “Logout”, the expected Runtime Objects shown are again:

  • LoginPage: 1
  • WebButton: 1
  • WebLabel: 1

With just “Login” (showing “Container Main”) and “Logout” → all great.

With “Login”, then “Container One”, then “Logout”:

  • a Dialog placed in “Container One” doesn’t get released
  • however, the shown “Container One” itself gets released

With “Login”, then “Container Two”, then “Logout”:

  • “Container Two” doesn’t get released
  • also still in Memory forever: “DialogAdd”, a WebMessageDialog
    • and WebControls such as Buttons, Labels (most likely those of the not released WebDialogs/WebContainers)

While Xojo can investigate the placed Issue… if someone would like to try this and find a way to get everything cleaned up upon “Logout” I’d appreciate that. I’d like to know if there’s some workaround to get that expected result (or point out where I’ve done something wrong in this silly, simple example while trying XojoWeb)…

…but meanwhile this most likely means for many Xojo Web Projects that it’s Memory is increasing steadily, requiring the WebApps to be restarted every now and then.

It would be interesting to know if others have placed WebDialogs in WebContainers, too - and if your get the same effect(s) in your real Xojo Web applications.

2

After a good night’s sleep I have found and fixed the issues.

See all detailed information in Issue 76039.

The issue with the WebTimer and it’s AddHandler one could blame on me (not really sure; maybe @Ricardo_Cruz can tell :wink: ).

However, there is one “Take away” everyone using Xojo Web should keep in mind:

WebDialog on a WebPage or a WebContainer

You have created a WebDialog which has an EventDefinition → so that it fires when the caller needs to be informed about something.

Don’t do that in the simple way by dragging-and-dropping an own/custom WebDialog into the Layout…!
This will cause the WebDialog to remain in Xojo Runtime forever. Every user/session showing a new instance of the WebPage or WebContainer containing this WebDialog will cause one more instance of the custom WebDialog to remain in Memory forever:

ContainerMemoryIssue
ContainerMemoryIssue2820×1640 375 KB

Workaround: Instantiate the custom WebDialog yourself…:

Var dialog As New DialogAdd
AddHandler dialog.AddItem, WeakAddressOf ActionAddItem
dialog.Show()

So don’t do it the “RAD”-way (by having Xojo generate and hook up the Instantiation and Events from the Layout), but do it all in own code…

Update: It’s not related to the own EventDefinition in the custom WebDialog. Even a simple/plain custom WebDialog placed like that on a WebPage shows this issue of not being released ever :frowning:

1 Like
3

I’ll have to take a look. Closing that WebPage should clean up its dialogs as well. Thanks for all the tests and info @Jürg_Otter!

1 Like
4

His sample crashes at load time on Win11 here.

Microsoft Windows [10.0.22631.3296]

App failing: Xojo.exe, version: 24.1.1.62582, Timestamp: 0x660d961d
Module failing: XojoWinUIFramework64.dll, version: 24.1.0.62582, Timestamp: 0x660cab63
Exception code: 0xc0000005
Offset of the fail: 0x00000000001f7492
C:\Program Files\Xojo\Xojo 2024r1.1\Xojo.exe
C:\Program Files\Xojo\Xojo 2024r1.1\XojoWinUIFramework64.dll
5

I’ve found a workaround to avoid the above condition.

Needed to open Xojo
Needed to create a new Web Project
Received a prompt asking for a firewall permission. Granted it.
My blank project opened for design.
THEN > File->Open and located Jürg’s sample
NOW it loaded and Xojo did not crash.

I’ve loaded it, but there is something going on…

Closing Xojo, and trying to load his sample directly, it crashes again.

It pauses here:

image

Then Xojo crashes like 3 secs after

6

I’m curious to see in Issues what you’ll see when looking into this - thanks in advance @Ricardo_Cruz .

I can give you one more :wink:

In Issue 76039 we have seen that a WebDialog only gets freed from Memory when being instantiated via Code (and NOT placed on a Layout, e.g. on a WebContainer Layout).

Now, with WebMessageDialog this is exactly the other way around :wink:
See example in separate Issue 76044.

So my “Take Away”'s are now (as of Xojo 2024r1) more complicated to remember…

If one currently wants to get all related objects released when closing a WebPage or a WebContainer, then:

  • custom designed WebDialogs → instantiate via Code, don’t place on a Layout
  • basic WebMessageDialog → place on a Layout, don’t instantiate via Code
1 Like