Project structure for Nsight remote debug/profiling for team using git, what files to commit?

Apologies in advance for being a newbie.

We are using Jetson TX2 and I’ve been able to do some remote debugging on it, using Nsight from a separate Ubuntu 16.04 host machine (actually in a VM hosted in Windows). That’s OK just for me.

However, I want to set up a project that other engineers can share in git in a sensible production environment. Any engineer should be able to check out the project, build the code, and debug it, without any local tinkering, and commit/push useful changes back to the source code repository for other engineers to pick up.

If we were to just use a makefile, that would be easy. Similarly if it was a Visual Studio project under Windows, we could share the same solution and project files, which use relative paths nicely. But Nsight/Eclipse seems to create a whole raft of hidden setup/configuration files (.cproject, .project, .settings/* etc). And importing a sample project (say) seems to copy everything locally to a workspace folder by default. Some settings will inevitably be engineer-specific (e.g. target Jetson board name/IP address).

I do want to work within Nsight, so that we can use the graphical debugging and profiling in what will become a very complex application. Yet I want to sensibly share the build amongst a collaborating development team without tripping over machine-specific settings or paths, if at all possible. I don’t want my build to work for me, but not a colleague. Should I just commit all of the hidden setup files? Is there some other well-known way? I’ve searched quite a bit, and not really found any consensus on handling Eclipse projects collaboratively in general, yet it’s used so much I feel there must be some sensible approach.

Thanks in advance for any tips or pointers!

Hi,

CVS and Git are supported by Nsight plugin.
Please check our document for more information:
http://docs.nvidia.com/cuda/nsight-eclipse-edition-getting-started-guide/index.html

Thanks.

I also have a similar problem, where it’s quite awkward to share the NSight project settings with my co-workers so we can collaboratively run/debug the same application on our own targets. It’s quite confusing how one can pull down a project (with the appropriate NSight project workspace). Ideally I could pull down a branch of Application ‘X’, with the Eclipse/NSight project configuration and just debug the application on-target.

I suppose there’s an idea that each person having their own NSight workspace (with their own preferences etc.), but I expect it’s just about knowing what project settings/files to commit (and what not to commit). Does anyone have any experience of this?

David.

Thanks, I’ll take a look at the git integration to figure out if it helps. (Not today though, it’s the office party!)

Hi,

Plugins is a new feature in Nsight EE 9.0.
CVS and Git are supported as IDE plug-ins.

It’s recommended to give it a try and share your experience here!
Thanks.

new feature in Nsight EE 9.0

Ah, I’ve only got Nsight version 8.0 (as installed as part of JetPack v3.1 on an Ubuntu 16.04 host). Does that mean I need to upgrade first, and if so how?

Also the Nvidia docs direct me to the Nsight online help for more information on git, but my installation from JetPack just comes up with HTTP error 500 (server error) when it tries to launch online help (using the URL http://127.0.0.1:37045/help/index.jsp). (Actually searching for ‘git’ in help topics in Nsight does list some topics, but clicking any help hyperlink in the search results just gives me that server error. And it’s not obvious where the help files might be installed.)

Thanks for your help!

Hi,

Sorry for the late reply.

Nsight EE 9.0 is available on JetPack3.2:

Please install it via JetPack3.2 directly.
Thanks.

Thanks, I installed JetPack3.2 without any problems under Ubuntu 16.04 running in a VMware Player instance under Windows 7, and let it reflash my TX2.

nsight v9.0 is not added to the default system path, but I can run it OK by going to /usr/local/cuda-9.0/bin and executing it from there in a terminal as ./nsight

But when I do Help… Help Contents within Nsight 9.0 I get the same http 500 error as with the v8.0 Nsight installation. As I launched it from a terminal this time, I see I get a whole load of errors when I do that (I’ll paste the beginning and end of those errors below).

Is there anywhere else I can read about the git integration, as the Nsight online help doesn’t seem to work?

PS I’m on holiday after today so apologies in advance if I go quiet for a couple of weeks…


Dec 19, 2017 8:37:31 AM org.apache.jasper.compiler.JDTJavaCompiler$1 findType
SEVERE: Compilation error
org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.(ClassFileReader.java:372)
at org.apache.jasper.compiler.JDTJavaCompiler$1.findType(JDTJavaCompiler.java:358)

at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:748)

Hi,

Happy holiday :)

We have checked the help function, and it can work correctly on our side.
The button opens the page located at http://127.0.0.1:49076/help/index.jsp

Not sure if this error is related to the VM environment.
A WAR is to use our online NsightEE document:
http://docs.nvidia.com/cuda/nsight-eclipse-edition-getting-started-guide/

Thanks and sorry for the inconvenience.

If you use a VM, then you may be in need of manually enabling any network port used in the VM to the VM.

Thank you both.

It’s not just me with my virtual machine; a colleague running Ubuntu 16.04 as the native OS has the same problem when he tries to launch Help… Contents from Nsight Eclipse 8.0.

I’ve tried replacing the loopback address 127.0.0.1 with the IP address of my machine assigned by DHCP, but that didn’t work. Also tried removing the (bridged) network adapter from my VM – I can still ping 127.0.0.1 then, which shows that loopback routing works to that extent, but the Nsight help still doesn’t work.

Given the ream of java errors that appear on the command line when I try and launch the help (see above), I think it is not a (loopback) networking problem, but some kind of java compilation that fails meaning that the help server process on my machine never gets started correctly. I get the same kind of errors with Nsight 8.0 or 9.0 when I try and launch the help (visible if I start the program on the command line). Maybe the way Nsight tries to launch a web server process using java when help is invoked depends on a version of the underlying java tools that differ from those in my installation or something like that.

A WAR is to use our online NsightEE document:

Unfortunately that online documentation just says:

Accessing CVS and Git repositories

…More information about these and other topics is available in the Nsight built-in documentation. To access Nsight documentation select Help->Help Contents from the Nsight main menu.

Never mind, to make some progress I think I’ll just have to commit EVERYTHING to git, including all the hidden settings files and directories, as a starting-point. Thanks though!

Actually my helpful colleague noted that the server process clearly was running, as the error page reported in the browser was generated by that server. (“Powered by Jetty://”). It is just that attempting to process the index.jsp file fails with the bunch of java errors on the command line, and error 500 (server error) returned in the browser.

Changing the help URL to a non-existent page at the same IP address and port gives a 404 not found error instead (so that is still an error generated by the help server process).

Changing the help URL to a different port just gives a connection error reported by the browser (Firefox).

So the browser was connecting to a server process which was returning data to be rendered in the browser. And the server found the file index.jsp. But it could not process index.jsp into a page, because it hit java compilation errors.

Hi,

Thanks for your feedback.
We are checking the JAVA error internally. Will update information to you.

Thanks.

Ah thanks. When I Googled it a bit, it seems to have been a recurring problem in Eclipse, so it probably isn’t an NVIDIA-specific issue. But if you find a workaround, that would be great!

If ssh is involved you may be encoutering a case where the server demands a more recent version than the one your eclipse uses:
https://devtalk.nvidia.com/default/topic/988099/nsight-eclipse-edition/is-ssh-private-key-remote-access-broken-in-cuda-8-0-nsight-/

Ah thanks for that. Actually remote debug using ssh works fine for me (in Nsight 8.0 and 9.0), and the broken help using a loopback connection to a server process just uses plain http not https.

Hi,

We have checked several computers but can’t reproduce this issue on our side.
Could you check if you can open a .jsp page in your environment?

Thanks.

I just tried searching from root level for any *.jsp files and don’t seem to have any (not even the Eclipse help causing the problem, oddly, I can’t find that in the filesystem, maybe it’s somehow hidden or generated dynamically).

There are several mentions of this kind of problem with Eclipse in the past but they seem to peter out in 2016, so maybe Nsight was branched from the main Eclipse development before it was fixed? E.g.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=493222
https://bugs.eclipse.org/bugs/show_bug.cgi?id=294390

I’m not looking at the git integration any more, so don’t worry on my account, though obviously it would be good to have Nsight’s help working for all users. Thanks for looking though!

Hi,

Thanks for your feedback.

We have updated your information with the internal team.
Will update comment here if any available suggestion.

Thanks

Hi,

Sorry for the late update.

1. This issue is caused when the JRE update to a newer version:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=495156

2. The workaround is to update the jasper plugin to a newer version.
org.apache.jasper.glassfish plugin (2.2.2.v201501141630)

Can be downloaded from here:
http://download.eclipse.org/tools/orbit/downloads/drops/R20140525021250/

Thanks.