2017-06-28 4:40 GMT+02:00 Alberthus <albert...@protonmail.com>: > Yes, that's the idea. > It is a problem i had quite often in the beginning, I searched on the > internet and also could'n find a solution. I ended up finding it by chance > when I was searching for something else. > When I first read about vgdb I thought, "what an awesome idea, get valgrind > and gdb to work together, I gotta learn it". There are still many things > that could be improved, one of those would be this small detail on the > documentation. Another thing that I think that is a idea worth working on is > to create a option that works simillar to break on gdb, but instead of > having a point where its supposed to stop it stops the execution at a memory > leak. The execution could be much slower, but it could save hours of work > searching for memory leaks for it would point pretty close to the root > cause. I don't know how valgrind works, but if could be done it would be a > life saver.
If you can propose a patch for the documentation bit mentioned above, that would be awesome. Source file for the relevant piece of documentation is found here: docs/xml/manual-core-adv.xml You can obtain Valgrind sources as described at http://valgrind.org/downloads/repository.html. Your other point was "instant" memory leak detection under gdb. However that is not how Memcheck (the default Valgrind analysis tool) works [1]. It searches for leaks at the end of the program run. It is however possible to perform incremental memory leak analysis under gdb+vgdb, see http://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands, gdb monitor command "leak_check". Once upon a time there was also an experimental tool called "omega" [2] [3] However I have no idea if it is still buildable with current Valgrind release and usable. It had also a design flaw which prohibited its reliable operation. I. [1] http://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks [2] http://www.brainmurders.eclipse.co.uk/omega.html [3] https://stackoverflow.com/questions/22517082/valgrind-how-to-understand-exactly-when-i-lose-control-of-a-pointer-to-a-memory > > -------- Original Message -------- > Subject: Re: [Valgrind-users] about VGDB > Local Time: June 20, 2017 2:03 AM > UTC Time: June 20, 2017 5:03 AM > From: iv...@ivosh.net > To: Alberthus <albert...@protonmail.com> > valgrind-users@lists.sourceforge.net <valgrind-users@lists.sourceforge.net> > > 2017-06-09 21:55 GMT+02:00 Alberthus via Valgrind-users > <valgrind-users@lists.sourceforge.net>: >> Hello, >> I"m new to programing and have been learning how to debug my program with >> gdb and find leaks with valgrind, and have been trying to do them both >> together using the instructions described in section 3.2 of >> http://valgrind.org/docs/manual/manual-core-adv.html >> I have been having problems finishing the valgrind session, the suggestion >> given by the answer at >> >> https://stackoverflow.com/questions/37731497/quit-valgrind-cleanly-when-debugging-with-gdb, >> works but is not always, is this the way it is expected we quit valgrind? >> Later on I also found by typing on gdb: >> (gdb)monitor help >> and I found the command v.kill that also worked for me. >> >> I suggest that you change the manual so that it will also teach a way to >> quit vgdb somewhere near where you teach how to use it, will be usefull in >> a >> documentation > > Hello Alberthus, > > So if I understand it correctly, you would like to see command > "monitor v.kill" listed in a subsection > of section "3.2. Debugging your program using Valgrind gdbserver and GDB"? > For example a new subsection called "3.2.5 Disconnecting GDB from > Valgrind gdbserver"? > > Let me know, > I. > > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users