|
From: João M. S. S. <joa...@gm...> - 2015-01-01 22:19:53
|
Let me correct myself: gdb catches the change on fd, but I thought it didn't because it didn't break the execution. It just got running 100% CPU and when I pressed ctrl-c it stopped in the culprit line. It always stopped on the same line which was strange but I didn't realize it was the line where the fd got erroneously modified. Now I ran it step by step with display of the variable and got it. On 01/01/2015 08:13 PM, "João M. S. Silva" wrote: > I moved the member variable from private to public because I thought gdb > needed it to be public in order to watch it. That's why I found out that > simply making it public would make the issue disappear. > > Now I tried watching it with gdb without making it public: it still gets > damaged, but gdb does not catch its change... > > (gdb) p pic.fd > $3 = 29541 > > On 01/01/2015 06:56 PM, David Goldsmith wrote: >> Using gdb you can put a watch on a variable or memory location. As soon >> as it changes the program will break and you can look at what the last >> instruction was. It probably won't seem to have anything to do with the >> fd itself, probably an array or something that's getting overwritten. >> I'd link to the relevant page on how to do this but my internet is out >> and I'm responding on my phone right now. > -- João M. S. Silva |