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 ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
