I’ve just upgraded our project to 1R7 targeting android 8.0 and I am unable to hit breakpoints in the java code.
I can hit breakpoints in c++ code without any problems, but Java breakpoints (when hovered over) say “The breakpoint will not currently be hit. Failed to find the Java class for this location”.
To verify that this is not an issue specific to our project I have just created a new project New Project->Nsight Tegra->Android Application and this has the same behaviour. If I put a breakpoint in line 15 of the unmofidied Android1.cpp file it hits it. But if I put a breakpoint on the first line of the Java Activity onCreate I get the same message as above.
I’m running VS Prof 2015 with the latest Codeworks installed. Pls Hlp.
Sorry to hear that you’ve experienced some inconvenience while using the product.
The described behavior could mean that the JVM debugger has failed to locate a directory containing Java .class files on the host PC.
This directory is located under the MSBuild project’s intermediate directory $(IntDir)
Try to figure out its path by searching for .class files in the project’s intermediate directory.
For example, for a sample project the class directory is "C:\AndroidApplication\Tegra-Android\Debug\build\intermediates\classes\debug\com\example\app"
One of the class files has the path “C:\AndroidApplication\Tegra-Android\Debug\AndroidApplication\build\intermediates\classes\debug\com\example\app\AndroidApplication.class”
Please add the path of the aforementioned class directory to the project property Java Classes Directories at the Debugging page as demonstrated on the attached screenshot: External Media
Please, make sure that Debug Mode is set to Java and Native code
Also, it helps to check the extension’s log file at %AppData%\Roaming\NVIDIA Corporation\Nsight Tegra\Logs\Nsight Tegra.log
Okay - it looks like the intermediates/classes folder is being put in the wrong place.
Where you are saying it should be - in Android1/Tegra-Android/Debug/build/intermediates/classes… it’s actually in Android1/Tegra-Android/Debug/build/build/intermediates/classes…
the path I added is:
Z:\AndroidTestProjects\Android1\Android1\Tegra-Android\Debug\build\build\intermediates\classes\debug\com\impromptu\androidtest
in this folder are the following files:
Mode LastWriteTime Length Name
Running the application with the Java Classes Directories set - and the Java breakpoints is still not working - same message as before when hovering over the breakpoint.
I have checked that the project is set to Java and Native Code.
Okay - So I looked at this again and put Z:\AndroidTestProjects\Android1\Android1\Tegra-Android\Debug\build\build\intermediates\classes\debug as the path and the Java breakpoint resolved and worked correctly.
So my questions are as follows:
Why is this not automatically setup as part of the project setup for 1R7?
Is there a hotfix that you can apply to this to make it work for any projects that we have?
Thanks for your report, we’re looking into it.
As of now, please use the suggested workaround for other projects.
Also, I would kindly ask you to share the full version of the Nsight Tegra VSE extension installed on your PC - the information can be copied from the VS’s About dialog.
Here is the about info…
NVIDIA® Nsight™ Tegra Development Platform, Visual Studio Edition 3.5.18222.5935
BUT…
So now I have breakpoints, but I have no locals or autos on my main project. I can’t hover over variables to get their value, but I can manually add watch variables.
On the Android1 test project I can sometimes get Locals, but no Autos, and no hover over variables. Manually adding variables to a watch window works okay - but very slow to expand.
Are others having this problem - or am I the only one using Codeworks for Android 1R7 on a real project?
Sir, I beg your pardon, but the reported inability to see the values of local and automatics variables is related to Java or C/C++ debugger?
In the case of C/C++ debugging, for an optimal debugging experience GDB needs a full set of DWARF debugging sections to be generated by the compiler and embedded into ELF shared libraries.
This means that optimal debugging experience is only guaranteed for the debug builds.
As an experiment, try switching to NDK r16, use a shared version of GNU STL, build your code with GCC 4.9 and link it with LD.BFD and see if it makes a difference.
Would you kindly share the log file captured for an example Java debug session?
Please restart VS before loading a project and starting a debug session.
I’m sorry to hear about this. Does it mean that the Java debugging experience was better with NT VSE 3.4 shipped with CodeWorks 1r6?