[support]

Thanks for finding this out. We have updated VisualGDB to create the TestMethod element as well (VisualGDB will only set the “name” attribute, as others are not relevant to the VisualGDB test logic). Please try this build: VisualGDB-5.5.2.3414.msi

If it still doesn’t work, please try manually adding other attributes present in the regular .trx file (e.g. codeBase, adapterTypeName) and let us know which combination of them fixes the problem, so that we could update VisualGDB to set them to some dummy values.

[support]

Please try updating to the latest preview build of VisualGDB: VisualGDB-5.5.2.3413.msi

The internal structure of the Teensy core has recently changed and may no longer work with the older VisualGDB versions.

[support]

Thanks for checking this. It looks like some minor structural differences between the .trx file generated by VisualGDB and the files expected by the Jenkins tools are interfering with the parsing.

Please try the following steps to diagnose it:

1. Create a dummy C# unit test with the MSTest framework. Run it with MSTest.exe and obtain a .trx file.
2. Update your Jenkins setup to use a fixed .trx file generated in step 1 instead of the one produced by VisualGDB.
3. Check if the test results are imported correctly. If not, double-check the Jenkins setup.
4. If the .trx file produced by MSTest works, but the one produced by VisualGDB doesn’t, try eliminating the differences between them. E.g. change the test names in one of the .trx files to match the other one and then try adding the elements present in another .trx file until Jenkins starts recognizing it.

Once you determine what part of the .trx file is interfering with Jenkins, please let us know and we will update VisualGDB to generate it in a way expected by the Jenkins tools.

[support]

Yes, we have published the tutorial here: https://visualgdb.com/tutorials/profiler/embedded/coverage/

[support]

Hi,

Due to privacy reasons, we do not post sensitive license-related information on the forum. Please contact our technical support for all licensing-related issues.

[support]

Hi,

As the error message suggests, please try checking the Output window for details. It will show a detailed build log including the lines that were not directly recognized as clickable error messages.

[support]

Hi,

It is hard to say why the specific thread would not be recognized without knowing the exact repro steps. If the problem only happens on a specific project/board combination, please try building our RTX plugin from sources and stepping through ReportThreadList() to see why a particular thread is skipped.

[support]

Thanks for clarifying this. In that case, indeed QEmu could one of the best bets, although configuring it would be non-trivial.

Generally, Qemu supports the gdb stub mode similar to VWMare, so we would advise the following configuration:

• Forward SSH port from the target to 10022 or any other port and specify “localhost:10022”  as the host name in VisualKernel.
• Enable the gdb stub mode in Qemu and use the “custom” mode in VisualKernel, directing it to connect to the specified host/port.

That said, due to low reliability of Qemu, this setup may trigger strange bugs, or not work at all.

[support]

Sorry, we absolutely do not support Qemu. It is extremely unreliable and difficult to configure. Please try using VMWare instead.

[support]

Good to know it works and thanks for the suggestion.

Unfortunately, automatically repairing broken package repositories would not be realistic. File system corruption is very unpredictable, so the exact repair actions would be completely different in each case.

As a workaround, unless you are debugging drivers for hardware that cannot be virtualised, please consider using VM snapshots as a way of recovering from file system corruption.

[support]

Thanks for posting the screenshots. It looks like the in the “correct” step the file is not saved. Could you please check whether the problem gets immediately triggered by saving the file, rather than building the project?

Also please try replacing the entire contents of the main file with this:

enum
{
    MY_TEST_ENUM = 1
};

void test()
{
    int x = MY_TEST_ENUM;
}

Then save the file and try going to definition of MY_TEST_ENUM. Does it work? If yes, try reverting to the old file contents and putting both the definition and the use just after the #include<> block.

If this doesn’t work, try putting it before the #include<> block.

If placing it just after #include<> block works, try keeping the definition on top and moving the use at the end of the file. If this triggers the problem, try locating a specific spot in the source file, after which the go-to-definition stops working. Most likely, it has some special character that confuses Clang. If you could eliminate the references to external code (so that it would load on our side), zip the repro file (to preserve encoding) and send it to us, we should be able to fix this.

 

[support]

Hi,

The AdditionalIncludeDirectories variable exists on the MSBuild level and is not generally passed to the VisualGDB level (to make things more complicated, it is not a global MSBuild variable, but a property of each individual ClCompile item).

To work around it, you would need to create a custom MSBuild target, translate %(ClCompile.AdditionalIncludeDirectories) into a global variable (just placing <PropertyGroup> inside the custom target might work) and then use the <Exec> task to launch the custom tool. The rest of the variables you mentioned are available both on VisualGDB and MSBuild level, so they will work in this scenario as well.

An easier alternative would be to create a basic property sheet defining the include directories (see the stm32.props file created by VisualGDB for embedded STM32 projects), referencing it from your project and parsing its contents from the custom tool. This will avoid complex MSBuild scripting and will still avoid having multiple redundant definitions of the include directories.

[support]

Sorry, we have not explicitly tested VisualGDB with Jenkins yet. Producing the .trx file with the /vsoutput option and then using the regular MSTest plugin should normally work. If not, please share the details and we will try to help you configure it.

[support]

Thanks for reporting this. We have fixed it in our development branch and will include in the next VisualKernel update.

[support]

Hi,

It looks like the linux-source-4.19 package got corrupt. Please try removing it via apt-get remove, deleting the /usr/src/linux* folders and letting VisualKernel reinstall it.

[Author]

Posts