[Bug]: UI general memory leak (drawers, modals, queries, possibly others)

[the-ocean-motion]

trafficstars

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

The web browser javascript heap memory size in a Lowcoder app keeps growing indefinitely as previously allocated objects are not released by the Javascript code. This can be observed by opening Window > Task Manager (google chrome) and enabling the JavaScript Memory column (right click on the column labels row to configure which columns are visible).

Expected Behavior

The user keeps interacting with the app, opening and closing drawers/modals for selected table elements. The javascript heap memory size should more or less remain the same throughout time upon a garbage collection and should not increase linearly (or exponentionally).

Steps to reproduce

This can be easily reproduced with the following steps.

1. Create a new App
2. Add a new drawer (drawer1) to the App
3. Add multiple text input fields to the drawer (e.g. 12 text input fieds)
4. Add new button to the App (not inside the drawer), with the label "Memory Leak Test"
5. Add a new event to the button that onClick executes the following javascript code:

`function delay(time) { return new Promise(resolve => setTimeout(resolve, time)); }

function openDrawer() { drawer1.openDrawer(); }

function closeDrawer() { drawer1.closeDrawer(); }

async function memoryLeakLoop() { for(let i=1;i<=500;i++) { setTimeout(openDrawer, 10); setTimeout(closeDrawer, 100); await delay(200); } }

memoryLeakLoop();`

6. Now preview the app. Make sure to copy paste the app preview url.
7. Close all Lowcoder tabs and paste the previously copied url to preview the new App
8. Now after the app loads open the chrome Task Manager.
9. Wait that the Javascript Memory field decreases and stops changing (or changing very little, meaning all initial app load resources have been released upon garbage collection)
10. Now press the "Memory Leak Test" button and wait that the drawer stops opening and closing.
11. Wait until the Javascript Memory decreases and stops changing again.
12. Now compare the Java heap size with the initial one and notice that the value is much higher (e.g. additional ~25MB that have not been released)

Environment

This was tested on https://app.lowcoder.cloud/ using google chrome, but the same happens in other browsers.

Additional Information

The problem gets worse when for example you have an app that displays a table. Upon clicking of a table row a "queryDetails" is called to retrieve the full information about that table row. A success even handler on queryDetails then opens up a drawer to show the full information of the table row, retrieved with the new query. As the user keeps clicking different rows of the table, Lowcoder doesn't release the memory used by previous executions queryDetails and the pace of increasing of the heap memory size is even worse.

[FalkWolsky]

Thank you for raising this serious issue. We will address it with priority.

[the-ocean-motion]

Thanks a lot, this one could be quite a huge problem for many organizations using Lowcoder.

On Wed, 18 Oct 2023 at 11:26, Falk Wolsky @.***> wrote:

Thank you for raising this serious issue. We will address it with priority.

— Reply to this email directly, view it on GitHub https://github.com/lowcoder-org/lowcoder/issues/406#issuecomment-1768148806, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEKNW4BITGXQERE2GF3VXVTX76VERAVCNFSM6AAAAAA6D5DAYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRYGE2DQOBQGY . You are receiving this because you authored the thread.Message ID: @.***>

[davidpiccinini]

Any update? My app keeps growing allocated memory when open drawers and modals

[FalkWolsky]

We hoped that it would be solved by an Update to the most current ANTd Version - but that seems not the case. So we will look again into the behaviour.

[davidpiccinini]

This fail its totally weird. Memory grows up to Chrome's tab fails and throw "Out of Memory".

I use queries, grids, modals and drawers. Now im trying to depure each part individually for known wich components are failling

Im using Docker self-hosted ver 2.2.1-2.2.1 #848d7866 (extract from editor's help menu)

[davidpiccinini]

I discovered the component that make memory increase is Stream Query (WebSocket). Thanks, I'll open new issue

[the-ocean-motion]

@davidpiccinini: that's an interesting finding, can you link the new issue here?

[FalkWolsky]

@davidpiccinini - can you give us more information? We are surprised. Does this effect happen, even if you do not use a Stream Query?

[davidpiccinini]

Sorry for long reply!

Hi! After 2 days of test. I have an update: remove websocket not fix the problem completely, only reduce memory usage. So, app take more time to fail.

BUT I noticed when the app's tab lost focus, all jobs/task was stopped. After focus was recovered, all jobs resume like a stack waiting show updates. For example, in some jobs a message is triggered, so when tab recover focus the message was triggered for each executed jobs (one by one, full-filling the screen from top to bottom like waiting to be showed). I think the reason is Chrome's -new feature- tab's discard due to inactivity.

Equally, if the tab remains open, the app rise memory consumiption until 1,2/1,5/2 GB.

Now these are the features on the running app:

• navbar with items
• 4 containers used for show each item of navbar
• the most important container have:
  • 1 grid paged by 6 items (each item has 2 text label (dynamic content loaded from API rest query -each 2 minutes or ws trigger- ) and a button)
  • a container with 3 buttons thats show/hide by API querys' data
  • 2 containers with a list each one -each list loaded date by API query each 2 minutes or ws trigger, and carried upto 100 items paged by 10; each item contains 3 text label (with conditional colors), 3 buttons
• whole app uses 10 api rest queries: Two were called each 2 minutes or ws trigger (for fill list). One is called on-demand by button triggers, and others only called on load
• all information (not available in data's queries) are saved inside temporal states. Mainly used in states and data transformation.

Even API rest queries are replies inside 1 secs from data origin, but in the app takes up to 7 seconds to show updated info (updated triggered instantly by websockets). All API queries show runtime below 3 seconds

In my opinion is a simple app. The higlight are: websocket, 2 list (with query associated) that bring a hundred of items

[davidpiccinini]

Any idea about the fail? It is normal a memory consumption of 2GB of RAM for LowCoder?

[the-ocean-motion]

Any update on this issue, was the memory leak reproducible via the steps above fixed in the meantime?