LinuxQuestions.org - [SOLVED] Warning in gdb, Having Trouble Debugging

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - Warning in gdb, Having Trouble Debugging (https://www.linuxquestions.org/questions/programming-9/warning-in-gdb-having-trouble-debugging-4175715192/)

Warning in gdb, Having Trouble Debugging

I'm having trouble debugging my program using gdb. I've got an error I've never seen before. I'm developing my program, currently, under Linux Mint. I won't go into details of the program I'm trying to debug.

So, what I do, is I start a new gdb instance, with my program, and the program my program is trying to run, which is correct syntax. I'm working on making the language object-oriented in the way that C++ is, that's all you need to know. So that's the type of program I'm trying to run.

Next, I set a breakpoint, right when my program starts to execute, with the break command. Then I run the program, which breaks right before my program starts to execute.

At this point, I can add the watch, with the watch command. So I do that. I tell it to watch reg.oclasses.data[1].itsname, which is a class's name, of a declared object. I'm trying to figure out where the program changes that, because it keeps being clobberred somehow. That leads to the program not working. At least that's the first bug.

I continue the program, no problem. Then I try to continue again, and this time I get an error. What's going on with gdb? What does this error mean? Why did I get it?

Code:

(gdb) break PNF::execute

Breakpoint 1 at 0x4292f8: file ../pnf.hpp, line 1954.

(gdb) run

Starting program: /home/des@smiley000.local/Documents/data/PNF/bin/LINUX/pnf class.pnf



Breakpoint 1, PNF::execute (this=0x0) at ../pnf.hpp:1954

1954        {

(gdb) watch reg.oclasses.data[1].itsname

Hardware watchpoint 2: reg.oclasses.data[1].itsname

(gdb) continue

Continuing.



Hardware watchpoint 2: reg.oclasses.data[1].itsname



Old value = <unreadable>

New value = 

      {str = {static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0}, _M_string_length = 0, {_M_local_buf = '\000' <repeats 15 times>, _M_allocated_capacity = 0}}}

PNF::execute (this=0x7fffffffca80) at ../pnf.hpp:1954

1954        {

(gdb) continue

Continuing.

Warning:

Could not insert hardware watchpoint 2.

Could not insert hardware breakpoints:

You may have requested too many hardware breakpoints/watchpoints.



Command aborted.

P.S. - Not asking for help with the program, and not trying to explain more than neccessary. Just want to know about the gdb error that I've never seen anything like it. I don't even know where to start to search for it. Is it a bug in gdb?

GDB Manual, section 5.1.2: Setting Watchpoints

Quote:

GDB sets a hardware watchpoint if possible. Hardware watchpoints execute very quickly, and the debugger reports a change in value at the exact instruction where the change occurs. If GDB cannot set a hardware watchpoint, it sets a software watchpoint, which executes more slowly and reports the change in value at the next statement, not the instruction, after the change occurs.
[...]
If you set too many hardware watchpoints, GDB might be unable to insert all of them when you resume the execution of your program. Since the precise number of active watchpoints is unknown until such time as the program is about to be resumed, GDB might not be able to warn you about this when you set the watchpoints, and the warning will be printed only when the program is resumed:

Code:

Hardware watchpoint num: Could not insert watchpoint

If this happens, delete or disable some of the watchpoints.

Watching complex expressions that reference many variables can also exhaust the resources available for hardware-assisted watchpoints. That’s because GDB needs to watch every variable in the expression with separately allocated resources.

As suggested in this StackOverflow answer, using the -location or -l option for watch may help.

Off-topic: It might be useful to run you program with valgrind and fix the problems it finds (which is many, considering the this=0x0 bit). Also if you use C++, make sure to learn this by heart.

Quote:

Originally Posted by des_a (Post 6370733)

I tell it to watch reg.oclasses.data[1].itsname, which is a class's name, of a declared object. I'm trying to figure out where the program changes that, because it keeps being clobberred somehow.

"data[1]" being wrong is a symptom of an array indexing bug. It may be faster to review all instances of "data" being indexed.
Ed

So, it must've been that array indexing bug, because I had only set the one watchpoint, and the one breakpoint. When I watched the whole data instead, it worked.

Unfortunately, the results were puzzling. So off topic, I think I will try valgrind. It confirms what I could find with my eyes, trying to watch it manually (more error prone). I see only two real places where it's being modified. The puzzling results are that my WRITE statements (I know it's not actually WRITE in C++, but the first book I ever read on it called it that), are saying, "Yes, it's modified." But my watching the data never shows that. Don't know what's happening yet, but I will eventually. Usually, when that's the case, they will agree with each other, even if a pointer or something overwrites it, watching the data will find that when the pointer is overwritten, it catches it as a WRITE. Unless it's my insert() method of my array or something...

Anyway, probably I will check it with valgrind, as suggested. Don't know which this that author means I should know. It points to a general C++ article, it looks like. Even though I've gotten few successful "large" programs written, that I did not lose in data loss, I'm hardly new to the language I'm using. I've been using versions of g++ and C++, since I was 15, which was about 15ish years ago, so I mean no disrespect to anyone and don't want to sound like a know it all either, but I do know about classes and the this pointer, if that's what the author was saying. I'm willing to continue to learn, and I love to learn about the language, if something else was meant.

However, unlike networking, I have not seen as many problems go on with the language or anything, so my troubleshooting skills are not as good as I'd like. I simply need to get this language I'm working on finished enough I can put it aside and work on other projects for now, that is.

Code:

To summarize, I know I'm wordy, found the problem with gdb, still bug hunting, Learning a lot about my tools, would love to learn more if someone can be more specific. Confused where the bug comes from for now, but trouble with gdb for now over. Looks like it was the array bug I was told about here, probably. "Closing and moving on, because I think I got gdb to work."

P.S. - I can see from valgrind, that although it says no leaks are possible, the very Linux Mint code and/or system C++ code that I'm relying on, has tons of jumps that depend on uninitialized values. In my own code, I've fixed as much as I can, without first fixing my library that I built. TO DO SOMEDAY: Fix it! I don't think it's my problem, but it certainly would help to check these things. I know that even with Linux Mint, if I wanted to, I could fix such things and redo the whole OS too, but that seems overkill for this project I'm working on, unless I'm certain that that point is where MY code breaks. But normally even then, I would simply work around it, so I'm not saying, "Hey try this new distribution, Linux Mint fixed!", but rather, try this new language, that works on every Linux Mint and other Linuxes, LOL! Of course, someday, I might work on Linux too, but that's not today, LOL!