- This topic has 5 replies, 2 voices, and was last updated 5 years, 4 months ago by
.
-
Posts
-
Hello,
Sorry if this has been asked before, but I cannot find any mention of problems with this at all hence this question.
I am trying to monitor when memory changes by using the VS (2017) data breakpoint feature. I setup the simple console applications shown on my images, on both Linux and Windows, start debugging via “Step into” then place a data breakpoint on the address of my pointer. Hence, when the pointer gets initialized, and then reset to 0, the breakpoint should be triggered.
This happens on the Windows project, but not the Linux project (see images): the hit count remains 0 on Linux, but (correctly) 2 on Windows.
My Linux box is x64; so is my Windows one but for some reason when I try and add a breakpoint set to fire when 8 bytes change, VS tells me the hardware does not support this…
This is a really powerful feature that has facilitated the tracking down of very complex bugs, so it would be a real shame if this does not work for Linux; hence I’d really appreciate you taking a look at this.
I am using VisualGDB-5.4.107.3203.msi, built as per request on this thread.
Thank you!
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.
Thank you!
The code I am running is
int main(int argc, char** argv) { int* p = new int; p = 0; return 0; }I have determined via the watch window (expression &p) that the address of p is 0x00007fffffffe9c8, and on each run it appears to be the same (I verify this of course!). I add a data breakpoint on this address (4 bytes).
If I enable the breakpoint, THEN step into the code, the breakpoint is hit several times (as in, the message box appears stating so!). I presume this is because the C runtime is manipulating memory as part of the course of starting my program…this shows that the functionality is working to some degree hence!
If on the other hand I step into the code, AND THEN enable the breakpoint, after verifying that &p is still the same (0x00007fffffffe9c8 here), then stepping over my two lines of code that adjust p, the breakpoint is not fired.
I ran “x 0x00007fffffffe9c8” in the GDB window as requested, all times the output was
x 0x00007fffffffe9c8 &"x 0x00007fffffffe9c8\n" 0x7fffffffe9c8: add BYTE PTR [rax],al OK
When I run past the end of main(), and hit F5 to continue debugging, I do get the breakpoint hit, but the callstack at this stage is
> libc.so.6!__run_exit_handlers libc.so.6!exit libc.so.6!__libc_start_main _start
…which is clearly not in my code. I expect a breakpoint to be triggered on both the new() call and the reset to 0.
I have attached my log. Hoping this can be of use!
Can you replicate this problem on your machine?
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.
Ah ok; I tried running instead of stepping and it seems that the breakpoints are indeed being hit; so it is clearly an issue with stepping that causes this.
Furthermore, I tried this on a separate machine, with the GDB ‘show version’ command outputting
(gdb) show version GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
…whilst the problematic RHEL box giving
(gdb) show version GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7
So one further possibility would be to try and update this version to a later one to see if that resolves it. But in the meantime, in this small piece of code at least, I know how to work around it.
Thanks for your timely support and responses!
- You must be logged in to reply to this topic.