[Jensa]

I get similar when I switch to a VisualGDB target from a Win32 one that was open by default. As in, I have both Win32 and VisualGDB targets in a solution. But for me it’s just a visual issue and closing the bar is enough and it builds correctly.

To reproduce it:
* Have both Win32 and VisualGDB targets in a solution. Set active to Win32 and close Visual Studio.
* Open Visual Studio with the same solution again.
* Change to the VisualGDB target and I always end up with that bar.

If I have a VisualGDB target active when I close VS so it is active when it starts again, everything works fine. I can switch back and forth between different VisualGDB and Win32 targets without any issues.
It’s just when Win32 was active when it started it happens.

[Jensa]

I prefer to Debug the tests though because it’s much easier to find and handle the occassional exception, assert or other rare error you may get while in early (or sometimes late) development.
Also we don’t just use the test frame work for small unit tests but for full system tests across multiple HW platforms and OSes plus with external HW dependencies so it’s not always possible to keep all tests 100% ok for all systems.

It’s a nice feature that someone probably enjoy but for me it’s causing me to stop using the Test Explorer for the VisualGDB targets and just debug the unit tests manually instead. But when you use it for windows projects you get used to how easy and convenient it is.
So for us an option to turn it off would be good.

[Jensa]

Thanks, that would work too I guess.

[Jensa]

Hi,

Got the time to work on some unit tests today again and it seems to work a lot better than before. It hasn’t tried to deploy anything except to the target I was actually targeting now.

Thanks!

[Jensa]

No, what I observed was that the test was still in the explorer like normally and VisualGDB tried to deploy it to the target (that in this case wasn’t connected) to identify it’s tests.
A clean didn’t help since it was unchecked in the build configuration so it didn’t clean it. Only manually deleting the output worked to avoid having it deoployed etc.
But I tested the same thing with a Win32 project as well and it was the exact same behavior there so It’s probably more of a VisualStudio issue in essence. Only a bit more annoying when its a remote target that’s deployed.

Attachments:

You must be logged in to view attached files.

[Jensa]

I haven’t really seen any issues with the test explorer or running tests with the new VisualGDB build. Also I’ve pretty much recreated all our projects to be able to cosolidate them into one project for all targets instead of having them separated by the target as we had before.

One thing I did notice now was that we have a couple of projects that are target specific only and not set to build for other platforms. But it seems that the unchecked “Build” box is ignored when it comes to test explorer and it’s features. Normally that wouldn’t be a big issue but since in this case its remote targets VisualGDB tries to connect to them to deploy the tests which in this case doesn’t work well since they may not all be connected when you’re currently targeting another platform.

I’m not sure if it’s an issue with VisualGDB itself or if it’s just how Visual Studio handles the test explorer internally. I tried disabling a Win32 project as well and it still showed up in the test explorer so it might be just a Visual Studio issue. But since it gets much more annoying when it’s a VisualGDB remote linux application I thought I would mention it here as well.

[Jensa]

Hi,

No problem. The new build seems to work fine.

Also it seems to work great with the test explorer running the bigger test projects that we have too, even with gdb. Though our biggest test project is something around 60k characters so I guess it was above a ssh limit but not the shell limit. Perhaps the issues you’ve seen where it doesn’t work was around the shell limit?
Either way it seems to work great for us now and it will be a long time before we’ll ever reach that 131k shell limit (if ever).

The only issues left that I’ve seen has to do with the test discovery. Now for instance one of the projects test didn’t get listed under the real project name but under the name “External”. All tests seem to be there and it worked perfectly to run them all though so it’s not a big issue.
I’ve also seen cases where it didn’t group them under the test fixture classes but had all tests directly under the project name. Also some cases where the “value parameters” got missing and it only showed the test fixture and one test each without the value parameter. We use the “Value-Parameterized Tests” a lot in our tests.
But I haven’t looked into those thouroughly since we had bigger issues with the tests not running before. Also so far I haven’t seen anything other than the “External” happen with the last build so it’s not a big issue.

Regards
Jens Nilsson

Attachments:

You must be logged in to view attached files.

[Jensa]

I got it working again, installed an older version (VisualGDB-5.6.105.4579) and then it worked again.
Tried to update to the latest one I got from you for another reason (VisualGDB-5.6.105.4583) and it doesn’t work again so it seems something is wrong with that version.

[Jensa]

Hi,

With that build it works perfectly!

Thanks!

[Jensa]

I got a bit better output when I tried to debug one of the projects, then I got some relevant output:

Locating deployed dependencies for project…
Locating deployed dependencies for project…
ShouldRedirectToVisualGDBImpl(): Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\OsLedGUnitTest-Ct150p-Arm-Linaro-6.2.1-Debug.vgdbsettings vgdb://TargetPath=Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest
Locating deployed dependencies for project…
failed to strip debug symbols from Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest: —————— qg3+w ——————

qg3+w: Failed to start process ($(ToolchainDir)\bin\arm-linux-gnueabi-objcopy.exe –strip-debug “Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest” “Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest-stripped”) in ” : The system cannot find the file specified —> System.ComponentModel.Win32Exception: The system cannot find the file specified

at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)

at qg3.f()

— End of inner exception stack trace —

at qg3.f()

at ng3.d2(z7 f, String b, String c, String a, ExpandedEnvironment d, CommandFlags e)

at p12.g1(String b, String g, String d, ModifiedEnvirionment f, td2 e, Int32 a, CommandFlags c)

at j91.j(DependentArtifact a, Boolean b)

trace=[qg3.f:71, ng3.d2:22, p12.g1:15, j91.j:564]

—————— Inner exception ——————

—————— System.ComponentModel.Win32Exception ——————

System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified

at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)

at qg3.f()

trace=[System.Diagnostics.Process.StartWithCreateProcess:1008, qg3.f:12]

Is it missing to evaluate the real path to the objcopy exe? “Failed to start process ($(ToolchainDir)\bin\arm-linux-gnueabi-objcopy.exe”
All other paths there seems to have been evaluated correctly and running the command manually from the project folder works perfectly and I get a stripped file in the output folder:
“X:\CT150\gcc-linaro-6.2.1-2016.11-i686-mingw32_arm-linux-gnueabi\bin\arm-linux-gnueabi-objcopy.exe –strip-debug “Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest” “Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest-stripped”

[Jensa]

When I enabled that logging I don’t really get that much there.

This is the only output I get when I do a “Project Only” -> “Rebuild” of one of our test projects.

Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Warning: test discovery took 1328 msec

In our case when we do it manually we’re using the ‘strip.exe’ instead of the objcopy to do it. I’ll see if the objcopy one works tomorrow.

Attachments:

You must be logged in to view attached files.

[Jensa]

It does and it works fine for us.

Did you remember to add the INSTANTIATE_TEST_CASE_P() macro to actually generate the code for them? The compiler errors you get are a bit horrible to figure out when it comes to the test code since it’s based on so much macro’s.

Another issue could be that I think the source code for the tests might be handled a bit differently when it’s from the package manager so it might be some issues with it realizing that the code needs some stuff that was previously optimized away depending on your compiler/link parameters.

[Jensa]

Ah, that must be the issue. For our projects we’ve followed the guide you have to have multiple VisualGDB platform targets with different names: https://visualgdb.com/tutorials/porting/multiplatform/
Then we’ve removed the default VisualGDB platform so we don’t get confused by it and only use the ones aptly named for the targets 🙂
So our solutions doesn’t actually have any platform called VisualGDB which it can find. Perhaps you should follow toolchain name and check in the folder that’s copied in the tutorial to see if other names are VisualGDB projects as well?

The other option the environment variable $(VISUALGDB_DIR) I do have that one when the projects are running but it’s not mentioned anywhere in the project files. Neither the completely new ones or our old ones.

[Jensa]

I tried to reproduce it with a fresh empty project but it seemed to work fine there. Perhaps there is something wrong with our project files that causes it to behave like this?

We still have the “Convert Project to MSBuild” option on them just below the “VisualGDB Project Properties” one. Clicking it just opens a window saying there are no configurations that can be converted though. That option isn’t there either on the new test project I created to test it. It was years ago however that we did that conversion though so I don’t remember that much about it except that it wasn’t as easy as just clicking the menu 🙂
Before testing for this I used the default VisualGDB platform target though and now while testing I created a new platform target for the test project and used the same as we have in our real projects and then the “Convert Project to MSBuild” menu showed up for the test project as well. It still worked and shows up the “VisualGDB Project Properties” directly from start on it though.

Our projects are a bit complicated since many of them contains platform targets for multiple linux systems and windows as well. Getting that to work has required a lot of manual editing of them to get the right references for the right projects. As in, one “high” level project could be identical for all platforms but reference 3 different “low” level projects for the HW implementation. We couldn’t get the references to work well using the Visual Studio GUI in this case (It doesn’t work well for Visual C++ either so don’t feel bad :)) so we edited the project files manually to get them to reference different projects based on their platform configuration.

[Jensa]

I still have the same issue with the R4 release (build 3031).

Opening a solution with visualgdb projects in it it actually works to build it but there are no visual “VisaulGDB Project Properties” available when right-clicking a project. Also debugging doesn’t work.
To fix it I still have to open the Help menu and open the “About VisualGDB” dialog. Then it takes a couple of seconds for it to load VisualGDB and then everything works again as expected.

Not sure if it’s different in any way but the way I open it is I have Visual Studio pinned to the taskbar and right click on it there and use the recent/pinned solutions to open it.

[Author]

Posts