[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.

[Jensa]

I’ve noticed the same issue.

I think the issues come with the decision to not start VisualGDB when Visual Studio starts but rather “when it’s needed”. The problem is I don’t think it works when you start Visual Studio and at the same time opening a solution with VisualGDB projects, IE starting it by opening a .sln file etc. Then it doesn’t seem to recognise that it should actually start VisualGDB.

My current solution is to just open the “HELP -> About VisualGDB” window. That will load VisualGDB and the properties appear.

[Jensa]

The source path in the “Debug settings” tab under “Deployment”. See screenshot.

Attachments:

You must be logged in to view attached files.

[Jensa]

Thanks for the tip,

The second option seemed simplest but I ran into an issue. The “Source path” in the deployment settings isn’t editable so I can’t change the application that’s deployed. It looks like it’s supposed to be editable though since it’s not greyed out but no caret shows up when trying to edit it and nothing gets changed when typing?

Regards
Jens Nilsson

[Jensa]

Thanks,

I can confirm that it indeed works again with that build.

• This reply was modified 7 years, 1 month ago by Jensa.

[Jensa]

Unfortunately ‘xargs –help’ doesn’t return anything other than:

BusyBox v1.24.1 (2019-02-12 12:52:35 CET) multi-call binary.

Usage: xargs [OPTIONS] [PROG ARGS]

We’re not able to update busybox for this target but I at least managed to build the SysprogsSync using our old toolchain and it was compatible enough to be able to run with it and sync so we can use that as a workaround for now.

[Jensa]

Hi,

I tried it again with that version and got a different error this time:

Using slow synchronization engine 'file-by-file'
Stderr line received 'xargs: invalid option -- '0''
Stderr line received 'BusyBox v1.24.1 (2019-01-22 14:14:26 CET) multi-call binary.'
Stderr line received ''
Stderr line received 'Usage: xargs [OPTIONS] [PROG ARGS]'

[Jensa]

Hi,

The “WriteFile failed” error was indeed probably from the same “null” error yes. Got it now and payed more attention to it and it was a null error at the same time. The additional logging says that it tries to write 2 characters only. Perhaps a new line or similar white-space characters that visual studio categorizes as empty?

Anyway, attached are test output and diagnostic console logs.

Attachments:

You must be logged in to view attached files.

[Jensa]

Hi again,

Now I got the crash error null exception error again and it looks like the callstack is the same as well. Using the build 2443 above:

[2018-09-25 15:19:25 Error] The parameter cannot be null or empty.
 Parameter name: message
 [2018-09-25 15:19:25 Informational] System.ArgumentException: The parameter cannot be null or empty.
 [2018-09-25 15:19:25 Informational] Parameter name: message
 [2018-09-25 15:19:25 Informational] at Microsoft.VisualStudio.TestPlatform.Common.Logging.TestSessionMessageLogger.SendMessage(TestMessageLevel testMessageLevel, String message)
 [2018-09-25 15:19:25 Informational] at VisualGDBTestExtensionShared.VisualGDBTestExecutor.ReportTestResults(String testContainer, bd ctx, IBasicStream stream, Dictionary2 selectedTests, List1 tests, IFrameworkHandle frameworkHandle)
 [2018-09-25 15:19:25 Informational] at VisualGDBTestExtensionShared.VisualGDBTestExecutor.RunTestsInSource(String source, Dictionary`
 2 selectedTests, IRunContext runContext, IFrameworkHandle frameworkHandle)
 [2018-09-25 15:19:25 Informational] at VisualGDBTestExtensionShared.VisualGDBTestExecutor.RunTests(IEnumerable`1 tests, IRunContext runContext, IFrameworkHandle frameworkHandle)
 [2018-09-25 15:19:25 Error] An exception occurred while invoking executor 'executor://visualgdb/TestRunner': The parameter cannot be null or empty.
 Parameter name: message

• This reply was modified 7 years, 6 months ago by Jensa.

[Jensa]

Hi,

We managed to find the bug without HW breakpoints now. But we’ll probably get to the point where we need it again and I’ll try the suggestions again then.

Thanks!

[Jensa]

Hi,

Today the testhost.x86.exe crashed while debugging some test cases. Was able to repeat it with the diagnostics console enabled and got the following logged:

Exception while forwarding test output: WriteFile failed, win32 error code 109
 ------------------ System.ComponentModel.Win32Exception ------------------
 System.ComponentModel.Win32Exception (0x80004005): WriteFile failed, win32 error code 109
 at u7.s(IntPtr a, Byte[] c, Int32 b)
 at ny.a()

The tests still ran however when it crashed and all completed successfully without errors.

Our biggest problem with these issues is that whenever something crashes or something all tests that wasn’t already run gets removed from the Test Explorer window. Sometimes we can then get them back by simply changing a line of code and getting the test project to build and identify tests again but that doesn’t always help either. Perhaps a workaround would be to not remove any test cases from the test explorer when something goes wrong and simply update the pass/fail of the test cases that did run before the crash. That would at least save us a lot of time so we don’t have to try and get the tests back and when they do the history is then lost.

Regards
Jens Nilsson

[Jensa]

Hi,

I tried it with the watch command and the command was successful but the watchpoint was still not hit then either.
After some googling I found I could change to SW watchpoints with the “set can-use-hw-watchpoints 0” and then they work. Unfortunately everything is way too slow then for my real applications so it doesn’t work there either.

The target type is Linux and I’m using a gdbserver. The target is a yocto based linux distribution on a imx6dl CPU which should theoretically support HW watchpoints. Unfortunately that’s beyond my embedded linux knowledge.

Thanks for trying!

[Jensa]

Hi,

I tried to add data breakpoints today when running VisualGDB build 2436 but they don’t seem to get hit even though that memory is written to. Is this still working or am I doing something wrong?

Tried both manually and using the context menu mentioned above but they are not hit when the memory is written to.

Regards
Jens Nilsson

[Author]

Posts