Running out of handles in LabVIEW 7.1

Question

Hi,
I'm having a problem with a LabVIEW 7.1 application running on Linux (2.6.12). About once a week the application crashes locking up the entire system.
While reproducing the problem at the office, it looked like the application ran out of handles. There was 1 network connection open, the listen task couldn't spawn a new one, untill the open one was closed. It didn't even matter if the connection was made from another PC. There also were problems with opening files (log files weren't updated anymore). The application has a couple of tasks, some of them weren't running anymore, some were.
Are there any known bugs for LabVIEW 7.1 for Linux?
Can anyone give me some pointers in solving this problem?
thanx,
Dennis

Answer 1

Dennisvr wrote:
Hi,   I'm
having a problem with a LabVIEW 7.1 application running on Linux
(2.6.12). About once a week the application crashes locking up the
entire system.   While reproducing the
problem at the office, it looked like the application ran out of
handles. There was 1 network connection open, the listen task couldn't
spawn a new one, untill the open one was closed. It didn't even matter
if the connection was made from another PC. There also were problems
with opening files (log files weren't updated anymore). The application
has a couple of tasks, some of them weren't running anymore, some were.   Are there any known bugs for LabVIEW 7.1 for Linux?   Can anyone give me some pointers in solving this problem?
Are
you sure you are closing all LabVIEW refnums properly you ever open.
TCP Listener refnums, TCP connection refnums, file refnums, each of
them will bind in internally to a system file handle under Unix and as
long as that LabVIEW refnum is not closed, will use up one of those
handles. LabVIEW only cleans up unclosed refnums after the top level VI
in whose hierarchy the refnum was created goes idle.
One thing to check out may be that the according Close function does
really close a refnum even though its "error in" contains an error
indication. That should be how it works but I've found in the past
areas where this didn't always be the case.
Rolf Kalbermatter
Message Edited by rolfk on 02-15-2006 11:02 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions