[Bug] Possible memory leak. Doesn't go away until you reboot about dxcam HOT 11 CLOSED

Hi Thordin, thanks for the report. Did you call camera.stop() upon exit?

from dxcam.

No I did not but I think it would call the __del__ method on that class upon exit right? The only time I closed the script was by pressing ctrl+c or if an exception was thrown.

I just realized I did not check the commit usage so this might be a false positive. I will continue running the script for a few days with the same settings and double check to make sure it isn't another program eating up the ram. But it would be strange if something was occupying so much commit, there shouldn't have been 6 gb physical free.

from dxcam.

I think I figured out the issue or at least 1 source of a leak.

I put a print statement in __del__ here.

It gets called if you don't use capture. However if you use capture, it will not get printed if the program quits.

I believe it is because the thread holds open a reference to the object so the object never gets garbage collected and never calls __del__, even if the thread is set to daemon.

from dxcam.

__del__ will have a similar logic, but __del__ on python can't be always trusted.(e.g. https://stackoverflow.com/a/6104568 and python gc documentation) So I would recommend calling .stop /.release explicitly to make sure everything is cleaned up. There are certainly more user-friendly ways to do the clean up and I will make improvement probably in next version.

As for the leak, I haven't tested it for running for days, but when I ran it for ~ an hour it maintains a constant memory footprint and cleaned up upon exit. I will double-check when I'm back from traveling.

from dxcam.

Not sure why this happens but this short little script causes an error when I release it.

import dxcam
import time

dx = dxcam.create()
dx.start()
time.sleep(2)
f = dx.get_latest_frame()
dx.release()

python test2.py
Screen Capture FPS: 54
Exception ignored in: <function _compointer_base.__del__ at 0x000001B21D44DA20>
Traceback (most recent call last):
  File "C:\Python310\lib\site-packages\comtypes\__init__.py", line 957, in __del__
    self.Release()
  File "C:\Python310\lib\site-packages\comtypes\__init__.py", line 1212, in Release
    return self.__com_Release()
OSError: exception: access violation writing 0x0000000000000000

from dxcam.

Try call .stop before .release:

import dxcam
import time

dx = dxcam.create()
dx.start()
time.sleep(2)
f = dx.get_latest_frame()
dx.stop()
dx.release()

Normally you don't need to call .release since the logic is handled in the destructor. But in the case of having memory issues, it's better to do it explicitly I guess.

from dxcam.

Try call .stop before .release:

import dxcam
import time

dx = dxcam.create()
dx.start()
time.sleep(2)
f = dx.get_latest_frame()
dx.stop()
dx.release()

Normally you don't need to call .release since the logic is handled in the destructor. But in the case of having memory issues, it's better to do it explicitly I guess.

According to the code, release calls stop as the first thing it does though.

from dxcam.

Just confirmed the memory leak. It happened again.

I tried connecting to the computer with remote desktop (parsec) it threw an error complaining about the video encoder not working. So I went to the machine physically, stopped the script, then found out it wouldn't start again.

  self.d3dshot = dxcam.create(max_buffer_len=2)
File "C:\Python310\lib\site-packages\dxcam\__init__.py", line 110, in create
  return __factory.create(
File "C:\Python310\lib\site-packages\dxcam\__init__.py", line 70, in create
  camera = DXCamera(
File "C:\Python310\lib\site-packages\dxcam\dxcam.py", line 30, in __init__
  self._stagesurf: StageSurface = StageSurface(
File "<string>", line 8, in __init__
File "C:\Python310\lib\site-packages\dxcam\core\stagesurf.py", line 20, in __post_init__
  self.rebuild(output, device)
File "C:\Python310\lib\site-packages\dxcam\core\stagesurf.py", line 44, in rebuild
  device.device.CreateTexture2D(
_ctypes.COMError: (-2147024882, 'Not enough memory resources are available to complete this operation.', (None, None, None, 0, None))

I checked task manager and physical ram/commit were under the limits. GPU ram however was stuck at 1.9/2.0 ghz with everything closed. Logging off the account was enough to release the memory.

So I think this is proof that some gpu memory is leaking, and not just an issue when exiting the script. dx.release() was already added before this run.

from dxcam.

Hi Thordin, thanks for the reply. Seems there's a memory leak somewhere. I'm trying to figure out the issue: Does your script /workflow involve multiple re-initializations? E.g. re-create of dxcam instance, output mode change, etc?

Possibly related:
https://forums.developer.nvidia.com/t/dxgi-outputduplication-memory-leak-when-using-nv-but-not-amd-drivers/108582

from dxcam.

Hello I have been editing and re-running my script multiple times.

I withdraw my claim about a memory leak from just leaving it running, there's maybe just the one caused by the release issue I mentioned above.

I increased my page file and it doesn't run out of memory after several days anymore.

from dxcam.

Cool. Good to know. Please let me know if there are any other issues.

from dxcam.