Error: Couldn't destroy session handle: The context is not bound

[KuleRucket]

Describe the bug
There is some kind of resource leak because each time cuda->freeStream() is called by the application the following error is raised:
Error: Couldn't destroy session handle: The context is not bound (see attached verbose log).

After this, the application works but after a few connect/disconnects, sunshine stops working and the host machine must be rebooted to clear the problem.

To Reproduce
Start sunshine
View log

Expected behavior
Error should not appear in log. resources should be reset read for the next stream to be initialised.

Screenshots
n/a

Host

• OS: Arch Linux
• Architecture: 64 bit
• Version: 0.11.1
• GPU Type: Nvidia
• GPU Model: RTX 3070
• GPU Driver/Mesa Version: 510.47.03 + nvlax patch
• Capture method (Linux only): PulseAudio/NvFBC
  

[ReenigneArcher]

https://www.dropbox.com/s/dwzpzzu0jynf8ou/sunshine.log?dl=0

Please use github gists to upload your log.

[KuleRucket]

https://gist.github.com/KuleRucket/d19b76cd655e796d5057f9489c355227

old link + file removed from Dropbox

[KuleRucket]

In addition, I also get "Error: Couldn't destroy session handle: Unable to cleanup NvFBC" when clients disconnect. It could be related. Here's and info log for this part:
https://gist.github.com/KuleRucket/d0f90f5797d3e133b154d6f1ea968b23

[KuleRucket]

I have done some further debugging and I see that each time a new session handle is created I get a new session handle identifier. I'm not sure it this is normal or it is related to the fact that nvFBCDestroyHandle() always fails. The resource leak is less severe that I thought. I seem to be able to keep starting/stopping sunshine indefinitely. The need for a reboot is caused by some other problem (possibly my GPU dropping the HDMI output after the screen has been off for a while).

So in short the error messages are still there but it does not seem to actually break anything. I will set up a timer to restart my sunshine service once a day to clear any possible resource leaks and hopefully that will be fine as a workaround.

[KuleRucket]

Solved problems with CUDA errors after sleep with the following, so no longer need reboots:
nvidia-smi --persistence-mode=ENABLED

Still have "Couldn't destroy session handle" errors during start up but they seem pretty harmless.

[ReenigneArcher]

Thanks for sharing your solution!

[wintervaler]

I was struggling with a similar error (Ubuntu 22.10 host, Nvidia 1050 Ti) and just fixed it, so I wanted to also share my solution for anyone that comes along hereafter. After suspend, Sunshine logs would say the following:

Jan 12 23:33:55 Info: CLIENT CONNECTED
Jan 12 23:33:55 Error: Failed to create session: The context is not bound
Jan 12 23:33:55 Info: Screencasting with NvFBC
Jan 12 23:33:55 Error: Couldn't allocate cuda array: cudaErrorUnknown:unknown error
Jan 12 23:33:55 Error: Couldn't initialize an image
Jan 12 23:33:55 Error: Couldn't allocate cuda array: cudaErrorUnknown:unknown error
Jan 12 23:33:55 Error: Couldn't destroy session handle: The context is not bound
Jan 12 23:33:56 Info: Setting default sink to: [sink-sunshine-stereo]
Jan 12 23:33:56 Info: Found default monitor by name: sink-sunshine-stereo.monitor
Jan 12 23:33:56 Info: Setting default sink to: [alsa_output.pci-0000_00_1f.3.analog-stereo]
Jan 12 23:33:56 Info: /CN=NVIDIA GameStream Client -- verified

And my client would say "connection terminated."

I enabled persistence mode with nvidia-smi -pm 1 (same as KuleRucket's solution above), but this wasn't sufficient. I had to enable some power management features, documented here and referenced here on the Ubuntu forums and here on the Arch Wiki.

Basically, you create a new nvidia-power-management.conf file to tell the driver to preserve video memory in a file somewhere other than the default. The Arch Wiki has a far better explanation than I am qualified to give, but hopefully this points folks in the right direction.

I had to enable the new systemd service, update my initramfs and then reboot, but now Moonlight reconnects to the Sunshine host after suspend just fine.

[KuleRucket]

Since then I have also needed to follow the Arch wiki and created /etc/modprobe.d/nvidia-power-management.conf and enabled the nvidia services. I have found in later nvidia drivers I had to enable both nvidia-suspend.service and nvidia-resume.service to be the display to sleep/wake properly. This is contrary to the Arch wiki which says nvidia-resume.service is not needed.