Hang on Debug Application

[cirrusio]

Hello all,

I am attempting to debug an RT application running on a PXI chassis and I am getting some frustrating behavior when I go to debug the executable using the Operate->Debug Application or Shared Library functionality.  Essentially in the Connection Status text box, the status runs through all the components (Downloading...) until it get to the main application itself and then just hangs.  I can not cancel and it never seems to connect (see image).  Does anyone have any thoughts?  I have some behavior that is occurring only when running my executable so I need to be able to see what is happening.

Thanks, Matt

[margasan]

Hello mtat76

Have you tried using a simple executable just to verify all exe´s have the issue. If other exe works just fine, you will have to disable sections of your code until you find the culprit

Regards

Mart G

[ColeVV]

I am seeing this behaviour on an application that I have built that is intended to be used on another PC.

I understand as margasan suggests that disabling portions until finding the culprit is probably the only recourse, however this is certainly annoying when the build time for my application is >5 minutes...

[cirrusio]

Hello Mart,

(I generally go by Matt 😉 )

Yes, other executables seem to be ok - this appears to have something to do with the size.  My problem is not necessarily that it has trouble connecting, but that I have no recourse when the system does not return properly other than to shut down LV through the Windows Task Manager. 

Regarding the suggestion - I understand where this is coming from and have done this when executable builds have failed altogether, but this seems about the equivalent of attempting to debug code using print "Here I am" statements peppered throughout. This is an excruciating way of attempting to solve this problem with large applications (cut code, build, download, attempt to connect, reboot LV, repeat cycle); surely NI has a better suggestion?  Are the engineers there familiar with this problem?  Should this be a CAR?  Am I the only one who has experienced this?

Cheers, Matt

[margasan]

Hello Matt

I am gonna check internally and let you know!!

Regards

Mart G

[ColeVV]

Hello Matt and Mart,

So I have narrowed down, in my application, the location of the bug (related to the GPU analysis toolkit). When the code bug is in the built executable (i.e. not disabled) I have a toggle for whether to process my data (where the bug is) or just save the raw data. In either case (process or raw), I see the same behaviour as Matt. The debugger gets to the main application and hangs. However, I do see it open up a "remote debugging window". I just can't interact with it. The application (running on the localhost for testing) can be run like normal and will run until the crash if I try to process the data or runs cleanly if I try to save the raw data. When I close the application, the debugger comes up with 3 save dialogs for these 3 files:

lvcublas.lvlib: CUBLAS Handle.lvclass has unsaved changes
lvcuda.lvlib: CUDA CSG Device Ptr.lvclass has unsaved changes
lvcuda.lvlib: CUDA Context.lvclass has unsaved changes

Then it puts up a "save multiple vi" for these two files:

lvgpusdk.lvlib:GPU Custom Data.lvclass
lvgpusdk.lvlib:GPU 1D CSG Array Data.lvclass

Where the changes are "Library Locked, Unlocked or password changed". This is a rather large application (I have unchecked "Disconnect Type Definitions", "Remove Unused Polymorphic VI Instances", "Remove Unused members of project libraries" and checked "Disconnect unused inline subvis" due to errors I was seeing in the compile process and their corresponding work-arounds found in the forums). The size of the application is ~48Mb.

When I put a diagram disable around the particular section that has the bug, I can connect to the application cleanly with the debugger, the application has "Control transferred to <machinename>" and I can run the application without it crashing. When I disconnect and close everything I don't see any of these saving windows (which makes sense because all the GPU stuff has been removed). The size of this application is ~32Mb.

Now to figure out what this error is...

Cole

[cirrusio]

Thanks, guys.

Cole - Although I haven't really probed it, but my system becomes increasingly sluggish with the size of the application.  Since I haven't really looked into it closely, I can't give specifics, but I have a hunch that this is not related to a single VI.  I am not using the GPU Analysis Toolkit, so that definitely is not the culprit for me.  My application is large with a LOT of objects (lots of OOP here).

Matt

[ColeVV]

Hi Matt,

I realize you and I are probably seeing the same effect from different causes. However, it seems to make sense that I just keep the issues I have been having within this thread rather than opening a new one.

Also, for my case, I had to restart LabVIEW and there was a failure log generated (attached). Matt, did you see anything like this? The default directory where these seem to be stored are "C:\Users\<user>\Documents\LabVIEW Data\lvfailurelog".