Unable to trace shared library with Desktop Execution Trace Toolkit

[DanyAllard]

Hello All,

I'm unable to trace shared library with Desktop Execution Trace Toolkit. 

I follow the instruction on the help and I'm not able to connect to my library.

There is my INI file of my dll:

[App]
server.app.propertiesEnabled=True
server.tcp.acl="590000000A000000020000002500000003000000090000003132372E302E302E311000000003000000000001000000000028000000030000000C0000003137322E32302E32322E363310000000030000000000010000000000"
server.tcp.enabled=True
server.tcp.port=3301
server.tcp.serviceName=""
server.vi.access="+*"
server.vi.propertiesEnabled=True
WebServer.TcpAccess="c+*"
WebServer.ViAccess="+*"
DebugServerEnabled=True
DebugServerWaitOnLaunch=False

Is there anything wrong with it?

Thanks

Dany

[DanyAllard]

Ok I found this link

---

224367 Return

Desktop Execution Trace Toolkit does not trance a LabVIEW built DLL called from LabVIEW Because of the way LabVIEW calls DLLs built in the same or different versions, DETT cannot trace a LabVIEW built DLL. Workaround: N/A Reported Version: 2009    Resolved Version: N/A    Added: 08/02/2010

---

That need to be fixed !  

Any plan for 2012?

[mudson]

Hello Danny,

Unfortunately, we aren't able to comment on products that haven't been released.

However, if you can tell me a little more about why you were running DETT, we might be able to help you fix something else.

Best regards.

[DanyAllard]

Hello Matthew,

The goal of using DETT is to find memory leak in DLL that I have compiled in LabVIEW. 

I have made a part of the job in source code, but to totally trace the behavior of my DLL it need to be built.

That architecture of my software is something like this:

App.exe   in LabVIEW

   |_ Toolkit Luncher.dll      in LabVIEW

             |_ Toolkit1.dll       in LabVIEW

             |_ Toolkit2.dll       in LabVIEW

             ...

             |_ ToolkitN.dll

And we have a remote API build in LabVIEW that use VI server

RemoteAPI.dll                 in LabVIEW using VI server to remote control the Toolkits.

Currently we have a memory leak that we need to identify and I want to tace my DLL to be able to determine if it's those that are the cause of the leak. 

Do you know other tool to track memory leak in DLL in general? 

[mudson]

Hello Danny,

If you are concerned about some operation in LabVIEW leaking memory, your best bet is to start the memory-leak hunt in the LabVIEW code.  I'm sure you have already gone through it, but a common source of leaks are references that are opened, but then improperly closed, or not closed at all.

If there is a lot number-crunching going on, it is important to remember that LabVIEW generally passes variables by value (variable in the text-based coding sense, not "little house icon" sense).  Everytime the output of an operation is sent to another point, a copy of that number is sent to the next operation.  This gets even more pronounced when there are multiple fan-outs from an operation.
This can be avoided by using an in-place structure.  The in-place structure permits accessing the variable by reference.  In cases where there is fan-out, using an in-place structure can create race conditions, so be conscious of how LabVIEW likes to parallelize code before using them.

Since the application you are needing to monitor is being compiled down into an executeable, external debuggers and memory profilers should work for what you are doing.  We have to be careful about recommending third-party applications, but several products of interest come up when I (insert search engine of choice) for "debugger" or "find memory leak".

[DanyAllard]

Thank you Matthew for your response.

I made a part of the job with the Desktop Execution Trace Toolkit finding Reference Leak. That is very useful feature because I work in legacy code that another company have done and now we are proprietary of the code and we need to find the source of the Memory Leak. There is a mixe of DLL involved in the executable, some in LabVIEW and some in C.

I already found a tool to find Memory Leak in C EXE and DLL called Glow Code that help me founding some source of Leak. But, it not trace LabVIEW DLL call.

If you have some news about LabVIEW 2012 and the capability of DETT. I have posted a question on the private Beta forums. And if you have some suggestion to make about software to find Memory Leak you can send me a private message.

Thank you

Dany 

[EricBehrs]

Any news on the referenced underlying issue 224367:

DETT cannot trace a LabVIEW built DLL.

If DETT can't access LV Shared Libraries and there is no intention to support this, then please remove it as a supported feature in the product literature and documentation (e.g. there is a DETT help topic titled Debugging LabVIEW Stand-Alone Applications and Shared Library Files).  Otherwise, please provide a status update regarding when the issue will be addressed.