Debugging

[CraigGraham]

I have an application that, after around a month of operation, dies hard
enough to knock out NT under Labview5.1.1. The memory usage of the system
increases linearly with time, although the memory used by the application
once array initialisation has taken place is static, save a couple of K per
day as a front panel string indicator logs activity. This has been verified
by a debugging program that uses the "Get Memory Statistics" program and
each minute saves various statistics for each individual VI in memory and
for the system as a whole.

Either I have a memory leak in an internal function or somewhere else that's
not seen by "Get Memory Statistics" or, more likely, I have a reference or
somesuch somewhere that I'm opening repeatedly and not
closing. Is there a
way of identifying how many open references a VI is holding so this can be
added into my normal debug program? It's much easier if you know which VI
has the bug than to have to check them all 🙂

[Jean-Pierre Drolet]

Maybe you can wrap the Open/Close VI Reference functions in VIs that logs
their call, (datalog at completion is often handy for debugging). You can
log opened VI name and the caller name or everything that is relevant to
you. Thus you can look back in the logs if there is one to one open/close
matches. When debugging is over, just disable data logging at completion.
It won't add noticeable execution overhead so you can let debugging wrappers
VIs in the application.

The "VI Path" input of "Open VI Reference" function accepts path and
strings. You can set this input to a path in the wrapping VI and convert
strings to path when the caller uses a string. Opening a VI reference with
"myvi.vi" (string) or "myvi.vi" (relative path) has the same effect.


I hope thi
s helps

Jean-Pierre Drolet


"Craig Graham" a écrit dans le message news:
3a0ab06d@newsgroups.ni.com...
> I have an application that, after around a month of operation, dies hard
> enough to knock out NT under Labview5.1.1. The memory usage of the system
> increases linearly with time, although the memory used by the application
> once array initialisation has taken place is static, save a couple of K
per
> day as a front panel string indicator logs activity. This has been
verified
> by a debugging program that uses the "Get Memory Statistics" program and
> each minute saves various statistics for each individual VI in memory and
> for the system as a whole.
>
> Either I have a memory leak in an internal function or somewhere else
that's
> not seen by "Get Memory Statistics" or, more likely, I have a reference or
> somesuch somewhere that I'm opening repeatedly and not closing. Is there a
> way of identifying how many open references a VI is holding so t
his can be
> added into my normal debug program? It's much easier if you know which VI
> has the bug than to have to check them all 🙂
>
>
>