Is this a bug in gdb

Is this a bug in gdb

[Volker Weißmann]

Hello,

The help text of the watch command claims that the -l option watches the
memory of the variable. When I tried this, I was surprised by the
outcome (reproducible):


(gdb) watch this->v_
Hardware watchpoint 2: this->v_
(gdb) watch -l this->v_
A syntax error in expression, near `restrict *) 0x00007fffffffd398'.
(gdb)

Note: Using print &(this->v_) and  watch (char[8])
*outputoftheprintcommand worked.


I am asking you whether this is a bug in gdb or not, because if it is a
bug in gdb, I will try to make a minimal example an file a bug report.


Greetings

Volker Weißmann

Re: Is this a bug in gdb

[Luis Machado]

On 2/16/20 7:40 PM, Volker Weißmann wrote:
> Hello,
> 
> The help text of the watch command claims that the -l option watches the
> memory of the variable. When I tried this, I was surprised by the
> outcome (reproducible):
> 
> 
> (gdb) watch this->v_
> Hardware watchpoint 2: this->v_

This command tells GDB to watch the value of this->v_, whatever address 
&(this->v_) points to. That, of course, can change across the execution 
of the program.

> (gdb) watch -l this->v_

This command tells GDB to watch for changes in a particular location. 
Since this->v_ is a value rather than a location, the error is thrown.

The correct invocation would be ...
> A syntax error in expression, near `restrict *) 0x00007fffffffd398'.
> (gdb)
> 
> Note: Using print &(this->v_) and  watch (char[8])
> *outputoftheprintcommand worked.
> 

... the above. It points to an address that will be watched.

> 
> I am asking you whether this is a bug in gdb or not, because if it is a
> bug in gdb, I will try to make a minimal example an file a bug report.

I don't think it is a bug. But maybe the documentation isn't doing a 
good enough job of making it clear how to invoke these commands?

Re: Is this a bug in gdb

[Volker Weißmann]

On 2/17/20 1:37 PM, Luis Machado wrote:

> On 2/16/20 7:40 PM, Volker Weißmann wrote:
>> Hello,
>>
>> The help text of the watch command claims that the -l option watches the
>> memory of the variable. When I tried this, I was surprised by the
>> outcome (reproducible):
>>
>>
>> (gdb) watch this->v_
>> Hardware watchpoint 2: this->v_
>
> This command tells GDB to watch the value of this->v_, whatever
> address &(this->v_) points to. That, of course, can change across the
> execution of the program.
>
>> (gdb) watch -l this->v_
>
> This command tells GDB to watch for changes in a particular location.
> Since this->v_ is a value rather than a location, the error is thrown.
>
> The correct invocation would be ...
>> A syntax error in expression, near `restrict *) 0x00007fffffffd398'.
>> (gdb)
>>
>> Note: Using print &(this->v_) and  watch (char[8])
>> *outputoftheprintcommand worked.
>>
>
> ... the above. It points to an address that will be watched.
>
>>
>> I am asking you whether this is a bug in gdb or not, because if it is a
>> bug in gdb, I will try to make a minimal example an file a bug report.
>
> I don't think it is a bug. But maybe the documentation isn't doing a
> good enough job of making it clear how to invoke these commands?

The reason why I thought that this might be a bug, is that I wrote the
following toy program to test it:

class MyClass {
public:
     int var = 0;
     void member() {
         var = 1;
     }
};
int main() {
     MyClass obj;
     obj.member();
     obj.var = 2;
     return obj.var;
}

Lets say I want to know why my program returns 2 and not 1. I can do
this like this:

(gdb) break main.cpp:5
Breakpoint 1 at 0x118c: file main.cpp, line 5.
(gdb) run
Starting program: /home/volker/Sync/DatenVolker/bugreports/gdb/a.out

Breakpoint 1, MyClass::member (this=0x7fffffffe344) at main.cpp:5
5               var = 1;
(gdb) watch -l this->var
Hardware watchpoint 2: -location this->var
(gdb) continue
Continuing.

Hardware watchpoint 2: -location this->var

Old value = 0
New value = 1
MyClass::member (this=0x7fffffffe344) at main.cpp:6
6           }
(gdb) continue
Continuing.

Hardware watchpoint 2: -location this->var

Old value = 1
New value = 2
main () at main.cpp:12
12          return obj.var;
(gdb)

In this toy program, watch -l this->var works, but in my large program
watch -l this->v_ did not. And I do not understand the difference.

Re: Is this a bug in gdb

[Luis Machado]

On 2/17/20 10:21 AM, Volker Weißmann wrote:
> On 2/17/20 1:37 PM, Luis Machado wrote:
> 
>> On 2/16/20 7:40 PM, Volker Weißmann wrote:
>>> Hello,
>>>
>>> The help text of the watch command claims that the -l option watches the
>>> memory of the variable. When I tried this, I was surprised by the
>>> outcome (reproducible):
>>>
>>>
>>> (gdb) watch this->v_
>>> Hardware watchpoint 2: this->v_
>>
>> This command tells GDB to watch the value of this->v_, whatever
>> address &(this->v_) points to. That, of course, can change across the
>> execution of the program.
>>
>>> (gdb) watch -l this->v_
>>
>> This command tells GDB to watch for changes in a particular location.
>> Since this->v_ is a value rather than a location, the error is thrown.
>>
>> The correct invocation would be ...
>>> A syntax error in expression, near `restrict *) 0x00007fffffffd398'.
>>> (gdb)
>>>
>>> Note: Using print &(this->v_) and  watch (char[8])
>>> *outputoftheprintcommand worked.
>>>
>>
>> ... the above. It points to an address that will be watched.
>>
>>>
>>> I am asking you whether this is a bug in gdb or not, because if it is a
>>> bug in gdb, I will try to make a minimal example an file a bug report.
>>
>> I don't think it is a bug. But maybe the documentation isn't doing a
>> good enough job of making it clear how to invoke these commands?
> 
> The reason why I thought that this might be a bug, is that I wrote the
> following toy program to test it:
> 
> class MyClass {
> public:
>      int var = 0;
>      void member() {
>          var = 1;
>      }
> };
> int main() {
>      MyClass obj;
>      obj.member();
>      obj.var = 2;
>      return obj.var;
> }
> 
> Lets say I want to know why my program returns 2 and not 1. I can do
> this like this:

I went to actually read the documentation (by habit i only use watch 
with the address itself) and i was mistaken. The -location option should 
take care of grabbing the address of whatever expression you passed to 
it. So ...

> 
> (gdb) break main.cpp:5
> Breakpoint 1 at 0x118c: file main.cpp, line 5.
> (gdb) run
> Starting program: /home/volker/Sync/DatenVolker/bugreports/gdb/a.out
> 
> Breakpoint 1, MyClass::member (this=0x7fffffffe344) at main.cpp:5
> 5               var = 1;
> (gdb) watch -l this->var
> Hardware watchpoint 2: -location this->var
> (gdb) continue
> Continuing.
> 
> Hardware watchpoint 2: -location this->var
> 
> Old value = 0
> New value = 1
> MyClass::member (this=0x7fffffffe344) at main.cpp:6
> 6           }
> (gdb) continue
> Continuing.
> 
> Hardware watchpoint 2: -location this->var
> 
> Old value = 1
> New value = 2
> main () at main.cpp:12
> 12          return obj.var;
> (gdb)

... this indeed is supposed to work.

> 
> In this toy program, watch -l this->var works, but in my large program
> watch -l this->v_ did not. And I do not understand the difference.
> 
> 

I'm guessing GDB got confused while trying to grab the address of your 
this->v_ expression. If you have a short testcase for that, it would be 
great to have this reported (if it isn't already).

Re: Is this a bug in gdb

[Volker Weißmann]

On 2/17/20 2:50 PM, Luis Machado wrote:
> On 2/17/20 10:21 AM, Volker Weißmann wrote:
>> On 2/17/20 1:37 PM, Luis Machado wrote:
>>
>>> On 2/16/20 7:40 PM, Volker Weißmann wrote:
>>>> Hello,
>>>>
>>>> The help text of the watch command claims that the -l option
>>>> watches the
>>>> memory of the variable. When I tried this, I was surprised by the
>>>> outcome (reproducible):
>>>>
>>>>
>>>> (gdb) watch this->v_
>>>> Hardware watchpoint 2: this->v_
>>>
>>> This command tells GDB to watch the value of this->v_, whatever
>>> address &(this->v_) points to. That, of course, can change across the
>>> execution of the program.
>>>
>>>> (gdb) watch -l this->v_
>>>
>>> This command tells GDB to watch for changes in a particular location.
>>> Since this->v_ is a value rather than a location, the error is thrown.
>>>
>>> The correct invocation would be ...
>>>> A syntax error in expression, near `restrict *) 0x00007fffffffd398'.
>>>> (gdb)
>>>>
>>>> Note: Using print &(this->v_) and  watch (char[8])
>>>> *outputoftheprintcommand worked.
>>>>
>>>
>>> ... the above. It points to an address that will be watched.
>>>
>>>>
>>>> I am asking you whether this is a bug in gdb or not, because if it
>>>> is a
>>>> bug in gdb, I will try to make a minimal example an file a bug report.
>>>
>>> I don't think it is a bug. But maybe the documentation isn't doing a
>>> good enough job of making it clear how to invoke these commands?
>>
>> The reason why I thought that this might be a bug, is that I wrote the
>> following toy program to test it:
>>
>> class MyClass {
>> public:
>>      int var = 0;
>>      void member() {
>>          var = 1;
>>      }
>> };
>> int main() {
>>      MyClass obj;
>>      obj.member();
>>      obj.var = 2;
>>      return obj.var;
>> }
>>
>> Lets say I want to know why my program returns 2 and not 1. I can do
>> this like this:
>
> I went to actually read the documentation (by habit i only use watch
> with the address itself) and i was mistaken. The -location option
> should take care of grabbing the address of whatever expression you
> passed to it. So ...
>
>>
>> (gdb) break main.cpp:5
>> Breakpoint 1 at 0x118c: file main.cpp, line 5.
>> (gdb) run
>> Starting program: /home/volker/Sync/DatenVolker/bugreports/gdb/a.out
>>
>> Breakpoint 1, MyClass::member (this=0x7fffffffe344) at main.cpp:5
>> 5               var = 1;
>> (gdb) watch -l this->var
>> Hardware watchpoint 2: -location this->var
>> (gdb) continue
>> Continuing.
>>
>> Hardware watchpoint 2: -location this->var
>>
>> Old value = 0
>> New value = 1
>> MyClass::member (this=0x7fffffffe344) at main.cpp:6
>> 6           }
>> (gdb) continue
>> Continuing.
>>
>> Hardware watchpoint 2: -location this->var
>>
>> Old value = 1
>> New value = 2
>> main () at main.cpp:12
>> 12          return obj.var;
>> (gdb)
>
> ... this indeed is supposed to work.
>
>>
>> In this toy program, watch -l this->var works, but in my large program
>> watch -l this->v_ did not. And I do not understand the difference.
>>
>>
>
> I'm guessing GDB got confused while trying to grab the address of your
> this->v_ expression. If you have a short testcase for that, it would
> be great to have this reported (if it isn't already).
Thank you for your help. I only have a large testcase for it, but I will
try to reduce it to a short testcase. After that, I will open a bug report.

Re: Is this a bug in gdb

[Volker Weißmann]

On 2/17/20 3:39 PM, Volker Weißmann wrote:
>
> On 2/17/20 2:50 PM, Luis Machado wrote:
>> On 2/17/20 10:21 AM, Volker Weißmann wrote:
>>> On 2/17/20 1:37 PM, Luis Machado wrote:
>>>
>>>> On 2/16/20 7:40 PM, Volker Weißmann wrote:
>>>>> Hello,
>>>>>
>>>>> The help text of the watch command claims that the -l option
>>>>> watches the
>>>>> memory of the variable. When I tried this, I was surprised by the
>>>>> outcome (reproducible):
>>>>>
>>>>>
>>>>> (gdb) watch this->v_
>>>>> Hardware watchpoint 2: this->v_
>>>>
>>>> This command tells GDB to watch the value of this->v_, whatever
>>>> address &(this->v_) points to. That, of course, can change across the
>>>> execution of the program.
>>>>
>>>>> (gdb) watch -l this->v_
>>>>
>>>> This command tells GDB to watch for changes in a particular location.
>>>> Since this->v_ is a value rather than a location, the error is thrown.
>>>>
>>>> The correct invocation would be ...
>>>>> A syntax error in expression, near `restrict *) 0x00007fffffffd398'.
>>>>> (gdb)
>>>>>
>>>>> Note: Using print &(this->v_) and  watch (char[8])
>>>>> *outputoftheprintcommand worked.
>>>>>
>>>>
>>>> ... the above. It points to an address that will be watched.
>>>>
>>>>>
>>>>> I am asking you whether this is a bug in gdb or not, because if it
>>>>> is a
>>>>> bug in gdb, I will try to make a minimal example an file a bug
>>>>> report.
>>>>
>>>> I don't think it is a bug. But maybe the documentation isn't doing a
>>>> good enough job of making it clear how to invoke these commands?
>>>
>>> The reason why I thought that this might be a bug, is that I wrote the
>>> following toy program to test it:
>>>
>>> class MyClass {
>>> public:
>>>      int var = 0;
>>>      void member() {
>>>          var = 1;
>>>      }
>>> };
>>> int main() {
>>>      MyClass obj;
>>>      obj.member();
>>>      obj.var = 2;
>>>      return obj.var;
>>> }
>>>
>>> Lets say I want to know why my program returns 2 and not 1. I can do
>>> this like this:
>>
>> I went to actually read the documentation (by habit i only use watch
>> with the address itself) and i was mistaken. The -location option
>> should take care of grabbing the address of whatever expression you
>> passed to it. So ...
>>
>>>
>>> (gdb) break main.cpp:5
>>> Breakpoint 1 at 0x118c: file main.cpp, line 5.
>>> (gdb) run
>>> Starting program: /home/volker/Sync/DatenVolker/bugreports/gdb/a.out
>>>
>>> Breakpoint 1, MyClass::member (this=0x7fffffffe344) at main.cpp:5
>>> 5               var = 1;
>>> (gdb) watch -l this->var
>>> Hardware watchpoint 2: -location this->var
>>> (gdb) continue
>>> Continuing.
>>>
>>> Hardware watchpoint 2: -location this->var
>>>
>>> Old value = 0
>>> New value = 1
>>> MyClass::member (this=0x7fffffffe344) at main.cpp:6
>>> 6           }
>>> (gdb) continue
>>> Continuing.
>>>
>>> Hardware watchpoint 2: -location this->var
>>>
>>> Old value = 1
>>> New value = 2
>>> main () at main.cpp:12
>>> 12          return obj.var;
>>> (gdb)
>>
>> ... this indeed is supposed to work.
>>
>>>
>>> In this toy program, watch -l this->var works, but in my large program
>>> watch -l this->v_ did not. And I do not understand the difference.
>>>
>>>
>>
>> I'm guessing GDB got confused while trying to grab the address of your
>> this->v_ expression. If you have a short testcase for that, it would
>> be great to have this reported (if it isn't already).
> Thank you for your help. I only have a large testcase for it, but I will
> try to reduce it to a short testcase. After that, I will open a bug
> report.

I managed to find a simple testcase: Turns out that gdb cannot watch
-location a restrict pointer. I wrote to bug-gdb@gnu.org

Re: Is this a bug in gdb

[Luis Machado]

On 2/17/20 10:34 PM, Volker Weißmann wrote:
> 
> On 2/17/20 3:39 PM, Volker Weißmann wrote:
>>
>> On 2/17/20 2:50 PM, Luis Machado wrote:
>>> On 2/17/20 10:21 AM, Volker Weißmann wrote:
>>>> On 2/17/20 1:37 PM, Luis Machado wrote:
>>>>
>>>>> On 2/16/20 7:40 PM, Volker Weißmann wrote:
>>>>>> Hello,
>>>>>>
>>>>>> The help text of the watch command claims that the -l option
>>>>>> watches the
>>>>>> memory of the variable. When I tried this, I was surprised by the
>>>>>> outcome (reproducible):
>>>>>>
>>>>>>
>>>>>> (gdb) watch this->v_
>>>>>> Hardware watchpoint 2: this->v_
>>>>>
>>>>> This command tells GDB to watch the value of this->v_, whatever
>>>>> address &(this->v_) points to. That, of course, can change across the
>>>>> execution of the program.
>>>>>
>>>>>> (gdb) watch -l this->v_
>>>>>
>>>>> This command tells GDB to watch for changes in a particular location.
>>>>> Since this->v_ is a value rather than a location, the error is thrown.
>>>>>
>>>>> The correct invocation would be ...
>>>>>> A syntax error in expression, near `restrict *) 0x00007fffffffd398'.
>>>>>> (gdb)
>>>>>>
>>>>>> Note: Using print &(this->v_) and  watch (char[8])
>>>>>> *outputoftheprintcommand worked.
>>>>>>
>>>>>
>>>>> ... the above. It points to an address that will be watched.
>>>>>
>>>>>>
>>>>>> I am asking you whether this is a bug in gdb or not, because if it
>>>>>> is a
>>>>>> bug in gdb, I will try to make a minimal example an file a bug
>>>>>> report.
>>>>>
>>>>> I don't think it is a bug. But maybe the documentation isn't doing a
>>>>> good enough job of making it clear how to invoke these commands?
>>>>
>>>> The reason why I thought that this might be a bug, is that I wrote the
>>>> following toy program to test it:
>>>>
>>>> class MyClass {
>>>> public:
>>>>      int var = 0;
>>>>      void member() {
>>>>          var = 1;
>>>>      }
>>>> };
>>>> int main() {
>>>>      MyClass obj;
>>>>      obj.member();
>>>>      obj.var = 2;
>>>>      return obj.var;
>>>> }
>>>>
>>>> Lets say I want to know why my program returns 2 and not 1. I can do
>>>> this like this:
>>>
>>> I went to actually read the documentation (by habit i only use watch
>>> with the address itself) and i was mistaken. The -location option
>>> should take care of grabbing the address of whatever expression you
>>> passed to it. So ...
>>>
>>>>
>>>> (gdb) break main.cpp:5
>>>> Breakpoint 1 at 0x118c: file main.cpp, line 5.
>>>> (gdb) run
>>>> Starting program: /home/volker/Sync/DatenVolker/bugreports/gdb/a.out
>>>>
>>>> Breakpoint 1, MyClass::member (this=0x7fffffffe344) at main.cpp:5
>>>> 5               var = 1;
>>>> (gdb) watch -l this->var
>>>> Hardware watchpoint 2: -location this->var
>>>> (gdb) continue
>>>> Continuing.
>>>>
>>>> Hardware watchpoint 2: -location this->var
>>>>
>>>> Old value = 0
>>>> New value = 1
>>>> MyClass::member (this=0x7fffffffe344) at main.cpp:6
>>>> 6           }
>>>> (gdb) continue
>>>> Continuing.
>>>>
>>>> Hardware watchpoint 2: -location this->var
>>>>
>>>> Old value = 1
>>>> New value = 2
>>>> main () at main.cpp:12
>>>> 12          return obj.var;
>>>> (gdb)
>>>
>>> ... this indeed is supposed to work.
>>>
>>>>
>>>> In this toy program, watch -l this->var works, but in my large program
>>>> watch -l this->v_ did not. And I do not understand the difference.
>>>>
>>>>
>>>
>>> I'm guessing GDB got confused while trying to grab the address of your
>>> this->v_ expression. If you have a short testcase for that, it would
>>> be great to have this reported (if it isn't already).
>> Thank you for your help. I only have a large testcase for it, but I will
>> try to reduce it to a short testcase. After that, I will open a bug
>> report.
> 
> I managed to find a simple testcase: Turns out that gdb cannot watch
> -location a restrict pointer. I wrote to bug-gdb@gnu.org
> 
> 

Great. Thanks for that.

Our bugzilla is here: https://sourceware.org/bugzilla/

You can open a ticket there. If you can't, let me know and I'll file it.