[Jensa]

Thanks,

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

• This reply was modified 5 years, 2 months 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 5 years, 7 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

[Jensa]

Hi,

Thanks for that fix. It improved it a lot.

I finally got some more time to work on our testing and got some more issues like the one above. Got this while trying to debug a single test I think:

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

The other error I got above is a bit tricky because it doesn’t seem to happen when I actually debug the code and neither when we just run the tests like a normal application. But I get it sometimes and when I get annoyed enough by it I’ll investigate more 🙂

• This reply was modified 5 years, 7 months ago by Jensa.
• This reply was modified 5 years, 7 months ago by support. Reason: formatting

[Jensa]

Thanks!

It now works great again.

Regards
Jens Nilsson

[Jensa]

Forgot to add that the buildnr is 2413.

[Jensa]

Last image since I was only allowed to attach 4 to previous post.

Attachments:

You must be logged in to view attached files.

[Jensa]

Hi,

See attached images for the available callstacks.

Attachments:

You must be logged in to view attached files.

[Jensa]

Thanks for trying 🙂

With VisualStudio it works fine to build and nothing seems to hang after it’s completed. As you can see in the log when using MsBuild it does work and it’s completely built the only problem is that MsBuild doesn’t exit after which causes our build scripts to hang.

I tried without the /t switch and it was exactly the same. The attached log was from a clean “Hello, World” project so unfortunately that doesn’t work either. Also tried now building on the remote target and it hangs at the exact same place.

A normal VC++ Win32 project works fine though which is why I posted it here and not at MS site.

See new attached logs of one VC++ and one VisualGDB remote build. This time I included the logged “CTRL+C” break at the end of the linux one which is the problem that it’s needed.

Any other ideas of what could cause this is appreciated.

Attachments:

You must be logged in to view attached files.

[Author]

Posts