LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Exporting in Desktop Trace Execution Toolkit gives "Memory error"; DTET memory usage

I'm currently using the Desktop Trace Execution Toolkit to debug a large LabVIEW application (Win 7 x64, 4 GB memory, LV 10.0 SP1 x86, Desktop Trace Execution Toolkit 10.0).

 

My application generates quite a large number of events, leading to a log containing about a million events. The log file on disk is a mere 50 MB, but already having this trace open in DTET makes it use

almost a gig of memory. Since DTET tends to be rather sluggish and primitive, I decided to try and export the log and view it in another application.

 

(As a side note: DTET is a nice tool, but compared to tools like SmartInspect, it's rather slow and primitive. Are there any plans to develop it further?)

 

Now when I try to export the log, DTET doesn't actually seem to export anything: no exported file appears in my file system. DTET's memoy usage does go up though, until finally it gives two error messages:

 

  1. Unspecified error occurred. VI "tt_fw_Main.vi:1" was stopped at unknown " " at a call to "tt_view_table_ExportData.vi"
  2. Not enough memory to complete this operation.
Is this a known problem? Are there any workarounds?
Thanks a lot!

 

Science & Wires — a blog on LabVIEW and scientific programming
http://scienceandwires.com
0 Kudos
Message 1 of 4
(2,680 Views)

Hallo,

I like to know that you did installed  SmartInspect in your PC after DTET's installation or not.

Because this software exports data as a .NET file in comparing with Desktop Trace Execution Toolkit which export data as .ttd or .txt files.

Besides, I'd like to know more about your setup too. Could you explain when exactly you got that errors? For example, after that you install DTET in your PC for the first exporting data or you could export data and you got error when you used another application.

 

I will hear from you.

 

Best regards,

 

 

 

0 Kudos
Message 2 of 4
(2,614 Views)

I am receiving a similar error.

 

LabVIEW: Memory is full.

VI"tt_fw_Main.vi:1" was stopped at unknown " " at a call to "tt_repository_Main.vi"

 

I have a large LabVIEW application (uses about 700 VIs and takes up about 100mB of RAM when in memory) which I am trying to debug. Any help as to why DETT is crashing would be appreicated.

0 Kudos
Message 3 of 4
(2,580 Views)

Hi, I found some info as it given below. Could you check that if you can use it too?

 

Hi Che,

I was able to diagnose the application crash and you can close this trouble ticket. The root cause was a race condition that occurred upon registration of an Event Callback with a COM server. Hundreds of these
were created while the COM server was firing events. I believe the issues is on the COM server side since LabVIEW locked up upon the property node
crash.
I was only able to trace this down with manual logging to file. I was able to resolve the memory issue with the DETT. Using the DETT I found a few references that were not properly closed.
I have added some comments to the Idea Exchange in regards to the memory limitations of the DETT:
http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improvements-to-the-Desktop- Execution-Trace-Toolkit/idc-p/1628284 It would be extremely useful if the DETT could log directly to disk to avoid the "out of memory issue".

Hi Brian,
> After investigating the current application it appears that in addition to the lockup, the "handles" in windows task manager are also slowly increasing. Is there a way to profile this with the NI tools? Handles refer to the number of object handles that the LabVIEW process owns. Since it's steadily increasing, it seems like the number of objects that are created are increasing too. This may give us some hint to what's happening with the memory.
> The application runs 24 hours a day and experiences an intermittent lockup after 6-8 hours of operation. There is a probable chance that it's locking up due to the memory filling up.
> The LabVIEW application is using around 900MB of memory but the "Profile Performance and Memory" tool only reports around 200MB for the "Avg Bytes" total of all items. There are many factors that could account for this. Since you're running your project in development mode, there is some overhead that is added due to the various functions such as probes, highlight execution, memory tracking, etc. The 200MB is what we would expect after you compiled your EXE and run it standalone.
> This suggestion should help with the memory usage. However, it does not provide enough logging for the intermittent lockup. What are your suggestions for the intermittent lockup in which a lot of logging information is required after 6-8 hours of operation?
Let's tackle one issue at a time. They're most likely related. With an application this large, we need to focus on issues once at a time, especially since it crashes in a short amount of time. So, let's do the following
-Create a trace that monitors Reference Leaks, Errors, and memory Allocations -Add a 'Get Queue Status' function and see if your queue is constantly increasing.
Let me know the results.

Hi Brian,
First of all, thank you for organizing the information into a concise, logical way. It makes it much easier to understand the situation.
The saving of the trace file cannot be automated. I was referring to the "File >> Save Trace" option, which it seems like you're familiar witih because you've attached a trace file.
-How long does your program normally run before it locks up?
Next steps: -Run VI Profile to see which VI is taking up the most memory
http://digital.ni.com/public.nsf/allkb/9515BF080191A32086256D670069AB68?OpenDocument
--Is it one VI that's taking up the most memory? Or is it many VI's that utilize a lot of memory?
-Create a trace that only monitors Reference Leaks, Errors, and Memory Allocations
-Add a 'Get Queue Status', and an indicator to the "# elements in queue" terminal to the part of your code that enqueues items (see screenshot) --Is it increasing? Or does it reach 0 for the most part?
Let me know how that goes.

Hi Brian,
DETT can run indefinitely, but it seems like this error is causing it to stop logging. There isn't a way to log it directly to disk. However, you can save existing traces to a file and create a new trace if needed. It sounds like your program may have a memory leak somewhere, and you're taking the right approach with DETT. It may be leaking enough to where DETT is experiencing an error
-Are you receiving the "Out of Memory" with LabVIEW or DETT? Can you attach a screenshot of the error message? (for instructions, see http://windows.microsoft.com/en-US/windows-xp/help/setup/take-a-screen-shot )
-With DETT configured to see everything (see dett_configure.jpg), are you seeing any RED or YELLOW entries in DETT? This references either an error or memory leak. (see dett_err_leak.jpg) -How much RAM do you have on your computer? -Are you using the "Build Array" function?
The following document describes why a program may be using too much memory,
http://digital.ni.com/public.nsf/allkb/C3C516C11184AF3F862571B5006B46E1?OpenDocument

 

Hear from you.

 

Regards,

Hossein

0 Kudos
Message 4 of 4
(2,569 Views)