LV 2015, Remote Debugging and Separate Compiled From Source Issue

[Mark_Yedinak]

Has anyone ever experienced an issue where the remote debug fails with the error "failed to connect to the application"? I am working on an existing project which is a few years old. Up until now it included the compiled code with source. This project is now being managed under source code control so I went through the project and marked all project VIs to separate compiled code from source. I had no issue doing this. The application ran fine in the development environment and was built as an exe without any issues. The executable ran just fine but when we went to investigate a bug we could not connect with the remote debugger. Going into the project and unmarking "separate compiled from source" and rebuilding allows us to connect the remote debugger.

I tried the usual with cleaning the compile cache and doing a clean before the build. None of this seemed to make a difference. I have many other projects which have the compiled code separated which we can use the remote debugger to debug the executable.

Any thoughts on what the issue might be?

[JÞB]

I'm going to ask two strange questions.

Did you build the exe and installer from a source distribution?  Re-reading your post it looks like you built from a project that contained source and later separated source without creating a SD.  Is that correct? 

Did you try to connect from the source distribution?  Again re-reading, It appears that as soon as you unseparated the source code (Effectively createcreating a SD) the debugger ran fine.  

Hmmmmm. My 8-Ball may be well calibrated today.  I look forward to your response.  (And that of anyone that can speak knowledgeably on those points) 

[wiebe@CARYA]

As a side note, I've been using scc for years and never needed to separate compiled code. I know the option is there for scc, but even with multiple developers I don't have much problems with this option off. AFAIK, It's only causing problems when the code needs a recompile on different check outs, e.g. when one developer has 32bit, the other 64, or one has Linux, the other Windows. Also, the repo's might be bigger... Optimize when needed.

[Mark_Yedinak]

No, it is not using source distribution. It is build direct from the folder where the ode was checked out. This happened on two different machines. We did see a strange error when we cleared the cache a rebuilt the application. It stated one VI was no loadable because it was compiled on a different OS. Opening this VI directly seemed to be fine and the subsequent build worked. I suspect that there is some corrupted compile in the cache and it is not be resolved after clearing the cache. I have not tried doing a mass compile on the entire repository. I may give that a try.

[Mark_Yedinak]

SSC works when you don't separate the compiled code from the source but there is WAY too much churn in the repository and it is very difficult to see what code actually has been modified. If you modify a typedef and 50 VIs use that typedef, fifty one files will get committed to SSC. Let's you actually modified a few of those VIs. When a bug comes up and you need to check where it might have been introduced you will not know which of those files were actually modified and which were simply recompiled. For small projects it might be manageable but when projects consist of hundreds of classes it becomes unmanageable.

[SaileshK]

Hi Mark,

Just to make sure you have remote debugging set up correctly, I have linked a document below which walks through all the steps of setting remote debugging up.

http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70

[wiebe@CARYA]

---

@Mark_Yedinak wrote:

SSC works when you don't separate the compiled code from the source but there is WAY too much churn in the repository and it is very difficult to see what code actually has been modified. If you modify a typedef and 50 VIs use that typedef, fifty one files will get committed to SSC. Let's you actually modified a few of those VIs. When a bug comes up and you need to check where it might have been introduced you will not know which of those files were actually modified and which were simply recompiled. For small projects it might be manageable but when projects consist of hundreds of classes it becomes unmanageable.

---

I'm on >2000 VI's in 242 classes (last time I checked). I hardly use typedefs anymore, as they are replaced by inheritance. The places where they still exist, they don't change much\ever.

I think it mostly makes a difference when connector panes change. That can trigger a recompile on all callers, even if the callers did not change.

Anyway, hasn't bothered me too much.

[Mark_Yedinak]

---

@SaileshK wrote:

Hi Mark,

Just to make sure you have remote debugging set up correctly, I have linked a document below which walks through all the steps of setting remote debugging up.

http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70

---

Yes, it is setup correctly. I can  remote debug if I set all the code to include the compiled code and it will not if I separate the compiled code. That is the only change made via the project file. I have switched up and back a couple of times with the same result.

[JÞB]

---

@Mark_Yedinak wrote:

---

@SaileshK wrote:

Hi Mark,

Just to make sure you have remote debugging set up correctly, I have linked a document below which walks through all the steps of setting remote debugging up.

http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70

---

Yes, it is setup correctly. I can  remote debug if I set all the code to include the compiled code and it will not if I separate the compiled code. That is the only change made via the project file. I have switched up and back a couple of times with the same result.

---

Which is why I asked about if you built from a source distribution

As seen in the Help

Do not separate compiled code from VIs that you intend to load or run using the LabVIEW Run-Time Engine. The Run-Time Engine cannot run source-only VIs because it has no access to the compiled object cache that stores the separate compiled code. If you intend for VI hierarchies that you check into source control to run on the Run-Time Engine, build a source distribution with the VIs.

Why such statements are included in the help is more than I know (Yippee! I get to learn something today) but it looks to me like you may have found at least one "Or Else"

[Mark_Yedinak]

I made sure there was no code being called dynamically. All the code should be packed into the executable. There is some weird corruption going on which I separate the compiled code from the source but I can't track it down.