Debugging with Desktop Execution Trace Toolkit

[Omar Mussa]

Has anyone tried using the Desktop Execution Trace Toolkit for debugging memory leaks? I tried to do it and I think it points me in a direction I can look into, but I'm having a really tough time getting useful information from the trace. Also, the export of data is in a format that is not very Excel friendly which also makes analyzing the data hard. If anyone uses this tool a lot and has suggestions, I'd appreciate it!

In my current trace, I'm only looking for memory events and looking for data >=400 bytes. I get events that show up, but I cant tell if they are a leak.

I've attached my 'trace' export but I haven't done any work on my own to try to parse it -- if anyone has already got tools for analyzing this data, great otherwise I'm not looking for someone to create one. I just attached it to show how non-trivial this process is.

3_30_2010 _ 08_20_47_832294.txt

[Cat]

No answers, just that I feel your pain. I too had code with a memory leak and talked my boss into letting me buy Desktop Execution Trace Toolkit. It didn't help any. I think if you have a really small project it might be useful, but there was just too much going on in mine and the trace buffer quickly filled up. Too quickly for it to be of any help (my memory leak wasn't evident until a few hours of run time).

Hopefully your boss will be more forgiving.

[Omar Mussa]

No answers, just that I feel your pain. I too had code with a memory leak and talked my boss into letting me buy Desktop Execution Trace Toolkit.

Ya, I don't have to worry about the try/buy decision. I tried doing more analysis and basically it looks like the app should have lost 2k of memory (which is counter to TaskManager which reported > 4k increase). I've attached my analysis. Either I need to change my trace parameters or the toolkit is not a great approach to fixing this issue -- have not figured out which is the case yet.

3_30_2010 _ 08_20_47_832294-formatted.txt

[Wire Warrior]

The DETT will allow you insight into the memory behavior of your program. Among other peices of information you can see every memory allocation call made by the program. The DETT also allows the inclusion of custom user events that can assist isolation of the program.

You can also use VI Profiler (located in the Tools Menu under the Profile >> Performance and Memory option) in the development environment that can assist in tracking down a memory leak one a per VI basis.

Jason

[windjmj]

How can I use the DETT 2016 to Debug the EXE(application)?

[hooovahh]

Settle down buddy, posting the same question in 3 threads isn't very polite.  As far as I know you can't use DETT on EXEs.  EXEs don't contain source, or the block diagrams, and many front panels are missing.  This makes debugging them very difficult.  If the application is stable in source, it would be very odd if it wasn't stable as an EXE.   Apparently you can and Mads has the details.

[windjmj]

13 hours ago, hooovahh said:

Settle down buddy, posting the same question in 3 threads isn't very polite.  As far as I know you can't use DETT on EXEs.  EXEs don't contain source, or the block diagrams, and many front panels are missing.  This makes debugging them very difficult.  If the application is stable in source, it would be very odd if it wasn't stable as an EXE. 

I'm sorry to posting the same question.Thank you for your answer.

[Mads]

You *can* use DETT on built applications, just enable VI server access and debugging in the build. Here is a description of it:

http://digital.ni.com/public.nsf/allkb/A50A8BBFD737679186257D7700688757

 

 

[hooovahh]

Thanks Mads for teaching me something new.

[windjmj]

On 2016/12/22 at 4:55 PM, Mads said:

You *can* use DETT on built applications, just enable VI server access and debugging in the build. Here is a description of it:

http://digital.ni.com/public.nsf/allkb/A50A8BBFD737679186257D7700688757

 

 

Thanks Mads.