[ Bug #19006 ] bug.n window list leak

[joten]

Import from berliOS:

Date: 2013-May-20 01:40
Submitted By: fuhsjr00
Assigned To: fuhsjr00
Category: None
Priority: 6
Bug Group: None
Resolution: None
Summary: bug.n window list leak

Original Submission:

If monitoring %APPDATA%/bug.n/data/_WindowState.ini, you'll notice that
it slowly grows over time.

Normal windows that are controllable by bug.n seem to get added and
removed as expected. However, pop-up windows (such as Win-R) get
recorded in the window list and stay. This also means that the window
forever remains in the internal Manager_allWndIds list because this is
exactly what is being dumped to _WindowState.ini.

I'm able to eventually get bug.n to saturate a core (_WindowState.ini
was around 260 lines with Config_maintenanceInterval set to 100ms). Once
this happens, bug.n is virtually unusable. However, the window count
doesn't seem to be the only factor because I can restart bug.n and see
CPU consumption fall back down to 1-2% with the same _WindowState.ini file.

Work-around:

Exit and restart bug.n. The _WindowState.ini file won't get smaller, but
the application may become usable again. If your WindowState.ini file
is ridiculously large, it is safe to delete window entries that don't
appear in the View* list. The windows of interest will not have
descriptions.

Followups

2014-Mar-05 21:11 joten
The problem might indeed be the use of Manager_allWndIds. This list
first was intended to allow restoring of windows, when bug.n crashed and
unintendedly left windows from an unvisible view hidden; therefore every
window is listed.
I added a comment in front of Manager_sync regarding Manager_allWndIds.
Manager_managedWndIds is used in Manager_cleanup, which previously
served a similar (but one sided) purpose as the session management.
Perhaps managedWndIds should be used in this case, too (?).
The questions also might be, if Manager_allWndIds is really used
anywhere in the current code rev.

[joten]

I could find Manager_allWndIds in versions 8.2.0 and 8.1.0, where it was checked in Manager_onShellMessage to add new windows, if they were not already in the list.

In the current version this is not done anymore; it is only used in Manager_saveWindowState. sync and cleanup use Manager_managedWndIds.

I had to go back all the way to version 3.5.1 to find the use of BREW_wins_id, which served a similar purpose and was still used in cleanup.

@fuhsjr00: Did you have anything specific in mind, when using Manager_allWndIds in Manager_saveWindowState? If you suspect windows to get lost, i. e. hidden by bug.n and falsely removed from Manager_managedWndIds, Manager_allWndIds would be the right list.

It could be made more efficient by only adding windows to Manager_allWndIds, if they were touched by bug.n, i. e. isManaged = 1, and not all windows found.
But if the list is meant to help recovering lost windows mismanaged by bug.n, it will have to be a memory leak, unless we can make certain that the window really does not exist anymore, when deleting it from all lists.

[fuhsjr00]

I think that maybe I misunderstood the purpose of Manager_allWndIds. I think that we only need the managed windows so that they can be re-managed if bug.n stops working. All the others shouldn't be needed.

Note that I'm assuming "isManaged" means "assigned to a view". I'm not sure what would be done with non-managed Windows.

[joten]

Note that I'm assuming "isManaged" means "assigned to a view".

Correct.

I'm not sure what would be done with non-managed Windows.

Nothing is and should be done with them by bug.n.

I think that we only need the managed windows so that they can be re-managed if bug.n stops working.

As far as I can see Manager__restoreWindowState does not restore falsly hidden windows (they are ignored). Would this be an optional feature -- restoring lost windows?
If so, we would need Manager_allWndIds as a 'copy' of Manager_managedWndIds without ever deleting a wndId from it. Else Manager_managedWndIds would suffice.

[fuhsjr00]

As far as I can see Manager__restoreWindowState does not restore falsly hidden windows (they are ignored). Would this be an optional feature -- restoring lost windows?
If so, we would need Manager_allWndIds as a 'copy' of Manager_managedWndIds without ever deleting a wndId from it. Else Manager_managedWndIds would suffice.

My thought on restoring accidentally hidden windows is to create a second process that records all Windows that are opened, removes them when they're closed, and watches the main bug.n process. If it detects that bug.n stops or fails, it should make sure that all Windows that should be visible are visible. By doing this in a second process, we make it very resilient to unexpected bug.n failures.

The save/restore subsystem might be able to handle this, but it relies on bug.n being restarted. However, save/restore bugs could still result in lost Windows, and those bugs are more likely since its responsibilities are more involved.

[Chadehoc]

I juste deleted a 10000 line long _WindowState.ini that was slowing everything. Why not for example an option that would just check at startup for unused entries in this file, and delete them? Restarting bug.n when too slow would be an acceptable workaround for me.

(edited because I had mistaken the "Closed" just above for this issue being closed)

[kashperanto]

Deleting my 5700 line long _WindowState.ini file has also helped tremendously. I was getting to the point where it would take 5-10 seconds to do a simple switch between two programs. I also had issues where suddenly I could not select one of my tiled windows, or where empty space got tiled. I do get quite a few popups, and one app I use produces unmanaged windows, so this at least makes some sense now.

[mattlyons0]

I've been using bug.n for a few weeks now and found my _WindowState.ini was 700kb. bug.n was terribly slow and yet after deleting is extremely responsive again. I think that even an option to delete the file on restart would be appreciated as I'd much rather re-organize my windows than wait 10-30 seconds to do a single operation in bug.n

[webframp]

Just confirming this is definitely still an issue. Minor manual maintenance of _WindowState.ini or just deleting it is an easy short term fix. I'm not familiar enough with the code or ahk syntax in general to really debug, but am willing to debug or test things.

[Leandros]

Any update on this?

[peterdweir]

I am not sure that bug.n is still in active development, but I love using it, and have learned a workaround for this bug that may help others. I have a shortcut on my desktop to the /Users/..../AppData/Roaming/bug.n/data folder that has two files in it. If _WindowState(.ini) gets too large (anything over 100-200 KB), bug.n gets really slow and hard to use. This is where the memory leak is being stored.

I use Notepad++ (which is free) to edit the file. I usually start by exiting bug.n (Ctrl-Win-Q), then right click on _WindowState & choose Edit with Notepad++. I click on Find/Replace in the menu or toolbar. Copy this into Find What and leave Replace With blank:
Window.;;;;;;.;0;\r\n
Click on Replace All, and all of the extra lines in the file that result from the memory leak will be removed. It may take Notepad++ a few seconds to do all of this if the file has gotten pretty large (or your computer is slow like mine). Save the file, and restart bug.n. All of the open windows will be in their old workspaces, along with the sizing, but it will work much faster.

The memory leak seems to be worst when I have let the computer go to sleep while bug.n is running. If it is very slow, this process, which only takes me about 30 sec or so repairs everything, but doesn't lose the way that bug.n has been set up. I hope this helps someone else.

[rollingmoai]

I am not sure that bug.n is still in active development

Looks like the latest commits say otherwise, I've switched to komorebi and haven't looked back ever since.