From: David Moerman on
I'm seeing a memory leak in tagsrv.exe on my laptop, where I use DSC
v8.2.  When I close the screen (suspend the laptop), and then open
it again (resume), the tagsrv.exe memory usage jumps dramatically,
often to over 125MB.  What is more, it appears each time I do this
the memory jumps again by this amount (I'm not completely sure how
consistent the incremental increase is, but I've often seen over 250MB
memory usage, and as high as 500MB).  Has anyone else encountered
this, or does anyone have a solution?

Thanks.

David Moerman
TruView Technology Integration Ltd.
From: Bassett Hound on
Hi David,
I have not encountered this with the DSC 8.2 module.  I assume you are monitoring the Memory usage using the task Manager?  Would you be able to provide a little more information about your system?  How many variables are you currently using and are you running an application at the time the memory jumps?  It would also be nice if you could provide before and after screen shots from when you hibernate you Laptop.
Regards,
Steven B.
From: David Moerman on
Attached are some images of memory usage.  Interesting, but the
problem does NOT occur if I simply hibernate then resume over a short
period of time.  The images you see are the result of hibernating
OVERNIGHT.  Not sure what to make of that.  I did not have
LabVIEW running when the memory jump occured.

The LV DSC project I'm working on has about 40 shared variables, many
of which are supposed to be connected to a Modbus/TCP client via
OPC.  However, during this development period I do not have the
hardware, so some shared variable errors result which I ignore. 
Also, I'm using a dataset I/O server to create batch-oriented datasets.

-Dave


memory1.GIF:
http://forums.ni.com/attachments/ni/170/206263/1/memory1.GIF


memory2.GIF:
http://forums.ni.com/attachments/ni/170/206263/2/memory2.GIF
From: Bassett Hound on
Dave,
I'll check and see if my PC will behave the same if I hibernate overnight.  I'll let you know how it goes in the morning.
Regards,
Steve B.