[support]

Thanks for the log file, it looks like our bug. We have fixed the problem in the following build: VisualGDB-5.4.108.3212.msi

[support]

No problem. If you encounter any further issues, feel free to get back to us and we will be happy to help.

[support]

Sorry about the attachment issues, we have updated our forum software to handle .log files properly.

Based on the log file, it looks like VisualGDB issues correct commands to gdb, but due to some reason, the RHEL gdb indeed ignores the watchpoint:

[ 595 ms] -break-watch *0x00007fffffffe9c8
[ 606 ms] ^done,wpt={number="2",exp="*0x00007fffffffe9c8"}
[ 874 ms] *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x000000000040063c",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeab8"}],file="LinuxProject2.cpp",fullname="/tmp/VisualGDB/c/temp/LinuxProject2/LinuxProject2/LinuxProject2.cpp",line="3"},thread-id="1",stopped-threads="all",core="1"
[ 4122 ms] -break-enable 2
[ 277085 ms] -exec-next
[ 277098 ms] *stopped,reason="end-stepping-range",frame={addr="0x000000000040064a",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeab8"}],file="LinuxProject2.cpp",fullname="/tmp/VisualGDB/c/temp/LinuxProject2/LinuxProject2/LinuxProject2.cpp",line="4"},thread-id="1",stopped-threads="all",core="1"
[ 277555 ms] -exec-next
[ 277566 ms] *stopped,reason="end-stepping-range",frame={addr="0x0000000000400652",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeab8"}],file="LinuxProject2.cpp",fullname="/tmp/VisualGDB/c/temp/LinuxProject2/LinuxProject2/LinuxProject2.cpp",line="6"},thread-id="1",stopped-threads="all",core="1"
[ 285940 ms] -exec-next
[ 285952 ms] *stopped,reason="end-stepping-range",frame={addr="0x0000000000400657",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeab8"}],file="LinuxProject2.cpp",fullname="/tmp/VisualGDB/c/temp/LinuxProject2/LinuxProject2/LinuxProject2.cpp",line="7"},thread-id="1",stopped-threads="all",core="1"
[ 286862 ms] -exec-continue
[ 286878 ms] *stopped,reason="watchpoint-trigger",wpt={number="2",exp="*0x00007fffffffe9c8"},value={old="0",new="-148686187"},frame={addr="0x00007ffff7233970",func="__run_exit_handlers",args=[],from="/lib64/libc.so.6"},thread-id="1",stopped-threads="all",core="1"

This might be caused by some interference between watchpoints and stepping. Please try checking if pressing F5 after enabling the watchpoint instead of stepping through main() works.

We can also help you reproduce the problem within a command-line gdb session, so you could check with RHEL support whether they can offer some workarounds.

 

[support]

The stray semicolon and the About window text are fixed in the following build: VisualGDB-5.4.108.3210.msi

As we wanted to minimize the amount of users affected by the broken Arduino downloads, we released the R8 installer in a very short timeframe with minimal changes required to resolve the package download issue (properly skipping the empty URLs in the package downloading logic). The stray semicolon is indeed shown in the default settings for R8, however it no longer causes any problems.

[support]

The memory breakpoints are actually handled by the target itself. All VisualGDB can do is request gdb to set one.

Please try creating a gdb log as shown here, then check that the breakpoint is requested/set at the correct address and not disabled when it’s supposed to trigger.

Please also use the “x <address>” command in the GDB Session window after setting the breakpoint and after it is missed to verify that the memory has actually been modified.

If it looks like the address used by VisualGDB is incorrect, or the breakpoint is not set properly, we should be able to fix it. Otherwise, it could be a limitation of your toolchain. If you are not sure, please attach a gdb log here and we will help you understand what is going on.

[support]

It looks like you have started the Go-to command and than canceled it. The message can be safely ignored.

[support]

Sorry about that, looks like our test environment inherited the settings from the previous build and did not catch this.

We have released a hotfix (5.4r8) that fully fixes the issue. Thanks for reporting this.

[support]

Please check the following setting: Tools->Options->VisualGDB->Common->GUI->Use classic black and white color scheme for consoles.

[support]

No problem. We have rechecked the TFS integration with the latest VS build and it looks like the Arduino projects were indeed not handling it correctly.

Please try this build: VisualGDB-5.4.107.3206.msi

If the message still appears, please select the “Use solution binding” option. The SCC icons should now work.

In order to eliminate the message completely, please enable View->Other Windows->VisualGDB Diagnostics Console (using the new build), create a new project in a source-controlled directory and let us know:

1. Whether the lock icons appear after you created the project
2. If yes, whether they reappear after you reopen the solution
3. The full log from the Diagnostics Console showing the messages from creating and reopening the solution

[support]

No problem, please try this build: VisualGDB-5.4.107.3203.msi

[support]

Hi,

Most likely, some other program (e.g. CMake itself) is using that folder and hence it cannot be deleted.

This can normally be ignored, as VisualGDB will delete every file and subfolder that is not being used.

[support]

The reason is the Visual Studio design. The regular disassembly window is a part of the debugging GUI and only appears during debug sessions.

To view the disassembly outside a debug session, please use the disassembly view in VisualGDB’s embedded memory explorer. It works independently from Visual Studio’s disassembly interfaces and was added exactly for this use case.

[support]

Please try Debug->Windows->Disassembly, or right-clicking anywhere in the source and selecting “go to disassembly”.

[support]

Unfortunately, the project file you copied is corrupt (e.g. the CMakeTargetSpecificSettings tag is not closed), so we were not able to reproduce the issue with it.

We have tried creating a similar project from scratch (ESP-IDF, CMake) and built it using the following command line:

VisualGDB.exe /build Project.vgdbproj /config:Release

This did work as expected. Please double-check that you are using the latest VisualGDB version and that the newly created project builds the release configuration as expected.

Then try comparing your project with the newly created one to see what setting could be interfering with the configuration selection from command line.

[support]

Hi,

Unfortunately, it’s hard to say what is going on without knowing more details.

Please describe exactly what you are doing after your start Visual Studio, what you expect to see and what you actually observe (see our error reporting tips).

Please also attach a screenshot of the entire VS window showing the loaded project in Solution Explorer and the missing menu commands and we will help you understand what is going on.

[Author]

Posts