I'm working on a project using Python in LabVIEW 2019 through the Python Node. The problem that I have is after the Python session is closed the NI Python Host process stays open and continues to use resources (viewing this in Windows 10 Resource Monitor). So over time more and more NI Python Hosts are running and the computer gets overloaded. I can force close them but would rather find out why it's happening. Is this something that is happening to anyone else using the Python Node or do I have a problem in my Python code that keeps it open?
I ran a simple function using the Python node in LabVIEW 2019 (example attached to this thread: Multiple-Outputs-from-Python-Node) and although by running it rapidly I was able to get 2 instances of NIPythonHost.exe in my Resource Monitor, I didn't see more than that.
In the time it has taken me to write this post, they have both disappeared.
I would guess that LabVIEW spawns these processes to handle Python node requests (and spawns multiple when there are many requests whilst others are busy, much like the handling of Shared Reentrant VI clones in a pool), and releases them when they are no longer needed.
If yours do not disappear no matter how long you wait, it may be that your python process is not terminating fully. Otherwise, I expect this is expected behaviour from opening multiple sessions simultaneously.
This thread is a bit old, but I noticed something similar in one of our applications. Did you figure out why it happens
No, I was never able to figure out why this is happening. I tried rewriting the Python code to make sure everything would exit correctly but nothing seemed to help. Everything functions correctly but after the Close Python Session I still have to force terminate all of the NIPythonHost.exe instances.
Thanks for the reply. I will update, if we figure it out. It happens in source code and running as executable. We see sometimes 4 or 5 niPythonHost.exe tasks with tasklist in a command line window, and we don't even run Python scripts often (LabVIEW 2018 64-bit, SP1 patch f4)
I'm seeing similar behavior with a complied LabVIEW application using the LV Python Node. My observation is the niPythonHost.exe process fails and hangs.The LabVIEW code containing the Python Node will not execute successfully until the niPythonHost.exe process is manually terminated.
In the Windows Event Viewer I see the following Application Error when niPythonHost hangs:
Faulting application name: niPythonHost.exe, version: 188.8.131.52154, time stamp: 0x5e5cf5f6
Faulting module name: VCRUNTIME140.dll, version: 14.0.24123.0, time stamp: 0x574290ad
Exception code: 0xc0000005
Faulting process id: 0x478
Faulting application path: C:\Windows\Program Files (x86)\National Instruments\Shared\NIPythonInterface\.\niPythonHost.exe
Faulting module path: C:\Windows\SYSTEM32\VCRUNTIME140.dll
VCRUNTIME140.dll is a C++ Runtime Library (2015). Exception code 0xc000005 is a memory access error.
My current theory is that I'm hitting a memory limit which is causing issues in the niPythonHost process. I think that for the following reasons:
Host: Windows 10
Target: Windows 10 (VirtualBox)
LabVIEW 2020 SP1 Runtime
I think I'm seeing something similar.
I just spent some time trying to understand why I was getting errors loading a DLL and it took me a bit to realize something was wrong with the state of the niPythonHost.
I got an error 1671 with the message "Python returned the following error: <class 'TypeError'> an integer is required (got type NoneType)". So I fixed that issue. On subsequent calls, I got "OSError: [WinError 1114] A dynamic link library (DLL) initialization routine failed." I spent quite a bit of time fiddling with things and googling thinking that this error was inherent to the code I'm executing before I figured out that killing the task niPythonHost task resolved the issue and the DLL loads fine as long as the Python host is in a clean state.
The scripts I'm trying to invoke run pretty quickly and I am opening and closing the Python session every time I execute a task, so I normally don't even see the niPythonHost appear in the task manager because it closes so quickly. When the type error occurs, it stays open through subsequent calls to the Close Python Session and even closing LabVIEW altogether.
I cannot say this behavior is specific to this error, but it isn't all errors. For example, "missing 1 required positional argument" doesn't hang the process and it terminates after the session is closed.