[support]

Hi,

Thanks, we have rechecked the updated example. VisualGDB currently only supports one test binary per project (we might be able to improve it in v5.4), sorry. As a workaround please try defining tests in static libraries and linking them into one large executable.

We also tried actually running tests in your project, however they did not report the results as the SysprogsTestHook_TestStartingEx() function was never called. This could be caused by differences between the test framework you are using and the one VisualGDB puts into newly created projects. Please try creating a regular MSBuild-based test project, setting a breakpoint in SysprogsTestHook_TestStartingEx(), reviewing the call stack and analyzing why it doesn’t get called in your project.

Naturally once we officially support advanced CMake-based unit tests, we will ensure it works out-of-the-box.

[support]

Hi,

Yes, v5.3 won’t handle this correctly unless you edit the file. It will be fully fixed in the upcoming v5.4.

[support]

Hi,

Strange, we have just double-checked that project on a different machine and it still worked. Please double-check the timestamp on the C:\Program Files (x86)\Sysprogs\VisualGDB\CppEngineCore64.dll file – it should be February 26th. If not, please double-check the VisualGDB version under Help->About VisualGDB and try reinstalling the temporary build we mentioned.

[support]

Hi,

Any edit to the source file should be sufficient to rebuild the related parts of the cache. If this still doesn’t work, please let us know.

[support]

Hi,

Unfortunately the way WSL allocates memory is completely outside VisualGDB’s control. Please try running the same project on a 64-bit Kubuntu VM, if the problem is caused by WSL-specific patches, it should help resolve it.

[support]

Hi,

Thanks, we have reproduced and fixed the problem. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2077.msi

 

[support]

Hi,

No problem. Feel free to follow us on Twitter to stay updated.

[support]

Hi,

Thanks for clarifying this. For Make-based projects VisualGDB uses a very basic logic to track references – it will read the target name from the referenced Makefile, and will combine it with the $(BINARYDIR) expression, assuming that the binary directories for both Makefiles are the same. The resulting path will be hardcoded in the EXTERNAL_LIBS variable of the referencing project.

If you prefer using Makefiles to MSBuild, please ensure all projects that reference each other have matching binary subdirectories. Another option would be to switch to MSBuild – in this case the project references are stored as actual MSBuild references and VisualGDB will compute the correct paths during build.

Yet another option would be to try Advanced CMake (VisualGDB can import CMake-based embedded projects, but cannot create them yet). This will let you build your projects outside VisualGDB, but will also provide much better flexibility than MSBuild.

 

[support]

Hi,

The debug part of the Linux kernel is relatively buggy – unless you are using JTAG or the VMWare debug stub that runs outside the kernel, the debugging functionality will run inside the kernel and may eventually lock up when the debugger-related logic tries to access some kernel resources that are used by some other part. VisualKernel does its best working around known instances of this, however there are still many cases when debugging is not reliable.

For best debugging experience we recommend using the VMware GDB stub that runs outside the kernel.

[support]

Hi,

Thanks for the logs. We encountered the issue during our internal testing, although it happened once every 10-20 debug sessions and did not interfere with debugging (VisualKernel used the slower symbol-based module listing mechanism and it worked without any noticeable side effects).

This could be caused by some race conditions during OpenOCD initialization. We can help you pinpoint and work around this, although we may need a few iterations with this, as we cannot reproduce the behavior you are observing on our side. Please try adding the “mon sleep 3000” command under VisualKernel Project Properties -> Debug Settings -> Kernel Connection -> Advanced Settings (before and/or after the target remote command). If this resolves the problem, please try experiment with reducing the delay.

If it doesn’t help, please try stopping the debug session via Debug->Break All and try reading the block that VisualKernel tried reading during initialization (e.g. x/16xb 0xbf05f940) manually by repeating the command shown in the GDB Session window. Does this produce a valid (non-zero) result after you stop the session manually?

[support]

Hi,

This could indicate a corrupt test framework cache. Please try deleting the %LOCALAPPDATA%\VisualGDB\TestFrameworks folder.

If this doesn’t help, please open the View->Other Windows->VisualGDB Diagnostics Console and try reproducing the problem again, then post the diagnostic output. This should help us pinpoint this.

[support]

Hi,

This looks like a known limitation of the address sanitizer logic caused by heap fragmentation. Please try following the advice from this thread, although your program might be simply too large for the address sanitizer to work correctly.

[support]

Hi,

This could happen if your code contained some definitions that would not be correctly parsed by Clang (normally it would result in errors in the Error pane). Feel free to attach a repro project and we will look into fixing this.

[support]

Hi,

This does look like a valid MSBuild-based project, so it should normally work (the problems you described are very similar to what happens when trying to generate a regular Makefile-based project). Please double-check that you are using the latest VisualGDB 5.3R8.

Either way, we can help you get this to work if you could let us know how you created the project, or you could simply wait 1-2 weeks for a preview build with the new ESP-IDF advanced project subsystem that will eliminate the need to use the BSP infrastructure that constantly gets out-of-sync with the rapidly changing ESP-IDF.

 

[support]

Hi,

This looks like VisualKernel fails to use the fast mechanism to query the module list. It could happen if the JTAG connection was unreliable and the memory reads were not succeeding. Could you please try attaching the full GDB log (in the “All GDB Interaction” mode) and the full output from OpenOCD? It may contain important clues.

Another thing to try would be to lower the JTAG frequency (try as low as 500 KHz first). If this solves the problem, the JTAG wiring might be at blame and double-checking/re-soldering it should solve the problem.

[Author]

Posts