[support]

Does your project use the ‘\r’ line endings? If yes, VisualGDB should show a bar that allows automatically changing them to ‘\n’. If not, the problem is likely caused by something else. If you could create a separate topic providing a detailed description of the problem you are observing, we will be happy to investigate this and provide a hotfix.

[support]

Hi,

No problem. Google indeed removed support for Ant-based builds from the latest Android SDK, switching it to Gradle and CMake.

The latest VisualGDB 5.4 fully supports both Ant-based builds with the older SDKs and the new CMake-based builds with the latest SDKs, so you can use any of those build systems depending on your requirements/preferences.

You can download SDK 2.24.1 directly from Google (we cannot mirror their packages due to copyright restrictions, but are happy to share the official download links): https://dl.google.com/android/installer_r24.4.1-windows.exe

[support]

Hi,

The easiest way to do this would be using the Quick Debug feature (see this tutorial). If you are building the code on Windows via a cross-toolchain, ensure you select it in the Quick Debug window and VisualGDB will locate the source files correctly.

A more long-term solution would be to import your existing build into VisualGDB using the Import mode of the Linux Project Wizard. Simply select “Import project built with other tools” and manually point VisualGDB to the final executable (e.g. Unreal exe). If you don’t want VisualGDB to control the build, simply specify a dummy build command line in the wizard (e.g. “echo done”) . Once the project is created, select “Attach to process” in the Debug Settings page of VisualGDB Project Properties  and disable automatic deployment via the first page of VisualGDB Project Properties.

Next time you debug the project, VisualGDB will attach to the executable of your choice using the cross-toolchain specified in the project settings.

If this doesn’t work, please let us know and we will be happy to provide further help.

[support]

Based on the log file, the test session actually starts, so the “missing test container” error doesn’t make sense. If creating a new project after reinstalling VS helped, most likely some global setting was corrupt and it affected some other setting in the project. If a newly created project works, please consider making a backup of it in case you run into the same problem again.

You could also try deleting the .vs folder in the broken project (also the Debug/Release, VisualGDBCache, etc) to see if that fixes the problem, but it may not be worth the effort if newly created projects work.

[support]

Thanks for the log. Looks like Visual Studio throws an error while VisualGDB tries to enumerate the test containers. It might not be related to the original problem, but either way we have added better handling for this here: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2757.msi

Unfortunately, you did not include the updated log from the regular View->Output->Tests (the registry setting would increase its verbosity), so there might be other issues preventing the tests from starting. If the updated build doesn’t solve the problem, please attach both VisualGDB Diagnostics log and the regular test output log.

Please also consider repairing your VS installation – the problem might be caused by missing components of the VS side.

[support]

Yes, even when using the Keil compiler, VisualGDB will internally use the GCC mode to query the project structure (VisualGDB reconstructs it from analyzing the GCC command lines). This should not affect the build, or cause any side effects.

Regarding the toolchain change, please try our latest internal build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2756.msi

If the toolchain change is still ignored, please check if the “Apply” button becomes active when you change the toolchain. If not, please consider sharing a screenshot of your project properties and we will try to reproduce it on our side and release a hotfix.

[support]

Hi,

Real-time watch is only supported for microcontrollers that allow reading the target’s memory without stopping the target. Currently only ARM devices support that feature.

Although it is technically possible on Linux-based devices like Raspberry Pi, VisualGDB doesn’t support it as the real-time view will not be accurate and would not cover library functions. Instead, for Linux-based devices (including Raspberry Pi), VisualGDB supports the valgrind profiler that can precisely measure the time spent in each function.

[support]

The test framework location should not be related. It looks like something on the VS side fails to load the test container.

Please try setting the following registry value (DWORD):

HKCU\SOFTWARE\Sysprogs\VisualGDB\Settings\ExtraVerboseTestExecutorLogging = 1

Then restart Visual Studio and try running the tests and then debugging the tests. Then share the Test Output and the output from View->Other Windows->VisualGDB Diagonstics Console.

[support]

Hi,

Please enable Clang IntelliSense for your projects while analyzing the code coverage. The coverage highlighting overlays are a part of it and won’t work with the regular VC++ IntelliSense (you can quickly switch between the two via a button on the Clang IntelliSense Diagnostics Console).

You don’t need to enable the code coverage instrumentation (i.e. injection of coverage code into the compiled code) for the main project. Simply choose “no” when VisualGDB suggests doing it after you enable code coverage via VisualGDB Project Properties. This will keep the code uninstrumented, but will let VisualGDB look for coverage reports produced by the referenced library projects.

[support]

Sorry about that. We do actually test our example projects and they do work out-of-the-box. Perhaps you have modified the default settings in a way the causes conflicts?

Either way, if you could attach the screenshots of the wizard steps you go through in order to create the project, we can advise you on what is going on.

[support]

Thanks for updating your email address, we have linked it to your forum profile. It does, however, look like your support period has expired a while ago.

Please renew your license here and we will be happy to walk you through the relevant VisualGDB settings.

[support]

Yes, we will try to add something similar in one of the next major releases.

[support]

Hi,

The file might be a part of a static library. Normally checking the output in the View->Output window should help find the full path of the files with both definitions.

Alternatively please try disabling syscall implementations via the first page of VisualGDB Project Properties.

[support]

Hi,

Sorry about that, it indeed looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2751.msi

Please replace the <Linux> section inside the %LOCALAPPDATA%\VisualGDB\TestFrameworks\com.sysprogs.unittest.googletest\TestFramework.xml file with the following lines:

  <Linux>
    <AdditionalSourceFiles />
    <AdditionalHeaderFiles />
    <AdditionalPreprocessorMacros />
    <AdditionalLibraries>
      <string>pthread</string>
    </AdditionalLibraries>
    <InitializationLines>
      <string>testing::InitGoogleTest(&amp;argc, argv);</string>
      <string>return RUN_ALL_TESTS();</string>
    </InitializationLines>
    <AdvancedTestDiscoverers>
      <TestDiscoverer xsi:type="OutputBasedTestDiscoverer">
        <TargetDemangledNames>true</TargetDemangledNames>
        <CommandLineArguments>--gtest_list_tests</CommandLineArguments>
        <TestGroupRegex>^(|[^/]+/)([^ \t/]+)\.$</TestGroupRegex>
        <TestRegex>^[ \t]+([^ \t/]+)(|/[^ \t/]+)($| )</TestRegex>
        <UniqueNameFormat>{1}{2}_{4}{5}</UniqueNameFormat>
        <StructuredInternalNameFormat>{1}{2}.{4}{5}</StructuredInternalNameFormat>
        <UserFriendlyNameFormat>{1}{2}::{4}{5}</UserFriendlyNameFormat>
        <SecondaryIDFormat>{1}{2}::{4}{5}</SecondaryIDFormat>
        <ShortUserFriendlyNameFormat>{4}{5}</ShortUserFriendlyNameFormat>
        <LocationSymbolFormat>{2}_{4}_Test::TestBody()</LocationSymbolFormat>
      </TestDiscoverer>
    </AdvancedTestDiscoverers>
    <TestSelection xsi:type="ArgumentBasedTestSelection">
      <GlobalArgumentTemplate>--gtest_filter=$(PerTestArguments)</GlobalArgumentTemplate>
      <PerTestArgumentTemplate>$(1).$(2)</PerTestArgumentTemplate>
      <PerTestArgumentSeparator>:</PerTestArgumentSeparator>
      <TestIDRegex>(.*)::(.*)</TestIDRegex>
      <IDType>SecondaryID</IDType>
    </TestSelection>
    <TestReportChannel xsi:type="PipeBasedTestChannelWithEnv">
      <PipeTimestampVariableName>g_SysprogsTestReportTimestamp</PipeTimestampVariableName>
      <EnvironmentVariableName>SYSPROGS_TEST_REPORTING_PIPE</EnvironmentVariableName>
    </TestReportChannel>
  </Linux>

We will publish an official update to our googletest package after the next maintenance release (R2) in the next few days.

[support]

Hi,

Thanks  for reporting this. We have fixed it in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2751.msi

[Author]

Posts