LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Desktop trace Execution toolkit memory overflow

Solved!
Go to solution

I have been trying to debug some possible memory leaks with desktop execution toolkit.  And what do you know - the toolkit crashes because it logs too many events! It doesn't seem to be possible to get it to log to file, or to do anything else. 

 

Aside from liking the irony that the toolkit that is supposed to track memory leaks has't got this sort of protection - has anyone managed to find a way around this?

 

(I know that this is a long running problem with this toolkit - see http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improvements-to-the-Desktop-Execution-Trace-Toolkit/id...

 

JP

0 Kudos
Message 1 of 4
(3,451 Views)
Solution
Accepted by topic author wideofthemark

Hi JP,

 

I'm sorry you are having difficulties with the Desktop Execution Trace Toolkit.

 

What version of the DETT have you currently got? Make sure you are using the most recent version as there have been many changes over the different version that have been released.

 

I noticed on the other forum post that you could alter the number of events which it caps at. Have you tried changing this setting?:

 

"The current implementation keeps all the traces in memory in order to keep up with the potential fast rate of events generated.  There's a setting in the TraceTool.ini file (MaxEvents=4000000) that specifies when the tool will stop tracing due to too many traces."

 

Kind Regards,


Larry Colvin
Associate Principal Engineer
Dyson Technology Ltd.

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

Thanks for replying.  I have the version that came with lv 2011.  Is this the most recent version?

 

I saw the editing ini file option in the previous post, but I guess i was surprised that what seemed to be a good suggestion 2 years ago didn't seem to have been implimented.  I'll have a play around with it and see what happens.

 

JP

0 Kudos
Message 3 of 4
(3,422 Views)

Thanks for the advice - changing the number does stop it crashing - although it gets to the point where it becomes less and less useful if you restrict the number of events it can follow.  I would strongly NI to impliment logging properly.

0 Kudos
Message 4 of 4
(3,411 Views)