Bug: Memory leak

[Richard Abrich]

After a while, python puterbot/record.py will cause the system to run out of memory.

[Richard Abrich]

First step: identify sources of memory leaks (there may be more than one!)

[Richard Abrich]

https://docs.python.org/3/library/tracemalloc.html

[Richard Abrich]

https://github.com/denis-ryzhkov/mem_top

[Angela]

After using tracemalloc and pympler to profile a few longer recordings with a lot of ActionEvents, this is the output I get:

From tracemalloc, the top 3 largest remaining memory allocations after Ctrl + C:

C:\Users\Angel\Desktop\OpenAdapt.venv\lib\site-packages\mss\windows.py:287: size=9041 MiB, count=3430, average=2699 KiB
C:\Users\Angel\AppData\Local\Programs\Python\Python310\lib\multiprocessing\reduction.py:51: size=9122 KiB, count=140, average=65.2 KiB
<frozen importlib._bootstrap_external>:672: size=3018 KiB, count=6951, average=445 B

It's clear that the first one is the largest by a landslide, and following the traceback I found that it came from the function that returned the screenshots, _grab_impl in windows.py.

Using pympler, I printed out the newly created objects each time a key was pressed:

types |   # objects |   total size
================================ | =========== | ============
                       bytearray |         256 |      1.98 GB
                            dict |         729 |    169.21 KB
                  main.Event |         622 |     38.88 KB
                             int |        1241 |     33.95 KB
       mss.screenshot.ScreenShot |         256 |     18.00 KB
                           float |         626 |     14.67 KB
                  mss.models.Pos |         256 |     14.00 KB
                 mss.models.Size |         256 |     14.00 KB
               collections.deque |           0 |      4.12 KB
                            code |           0 |    386     B
                      memoryview |           2 |    368     B
              _winapi.Overlapped |           1 |    168     B
                            list |           2 |    144     B
         ctypes.c_wchar_Array_22 |           1 |    120     B
  pynput.keyboard._win32.KeyCode |           1 |     48     B

The bytearray was always the largest, which also points towards the screenshots being the issue.

Since the screenshots are put in the event queue in a loop, it seems like the most likely reason is that when a lot of input is given by the user, screenshots are put into the queue faster than they are removed from the queue, causing a pile-up of screenshots remaining in the queue.

[Richard Abrich]

@KrishPatel13 @angelala3252 can you please confirm whether this fixed?