|
From: Nicolas S. <nic...@ya...> - 2018-02-20 13:08:35
|
Tomas, Timers, threads ,"real time behaviour" of your application and GDB may jostle each other, so you may not be able to use it. What you can do is getting a valgrind report as usual and, from this report, understand where the issues are. Then you instrument your code using VALGRIND_PRINTF_BACKTRACE(). Of course nothing is automatic. Hope it helps you in your investigations. Nicolas. -------------------------------------------- En date de : Mar 20.2.18, Tomas Vondra <tv...@fu...> a écrit : Objet: Re: [Valgrind-users] how to generate core file on invalid reads/writes? À: "John Reiser" <jr...@bi...>, val...@li... Date: Mardi 20 février 2018, 1h50 On 02/19/2018 11:14 PM, John Reiser wrote: >> Is there a way to get core when valgrind on invalid access? Am I >> missing something? > > If you are running valgrind interactively and valgrind reports an error, > then one of the error options is to invoke gdb. Gdb has a command: > generate-core-file <filename> > See the gdb manual which is available online in html. > Interesting. Shame on me for not knowing about the gdbserver thing! I wonder what exactly does "interactively" mean here. I'm running it as part of an automated regression test suite that starts postgres, and executes a bunch of SQL scripts on it. If I understand the docs correctly, this qualifies as interactive. I'll try tweaking the scripts tomorrow to use the --vgdb options. > If you start valgrind with the option --vgdb-error=<number> > then you have a gdbserver process which provides *much better* > service than attaching gdb only at the point of error. > See the valgrind manual, or "valgrind --help" for a synopsis. > > In either case the core file will include the pieces of valgrind > which are running in the same process [and address space] > as "your" program. So you might become confused while separating > what is "your" program from what is valgrind. > > For practical purposes (shortest time to finding and fixing > the "first" error) it often is best to use the --vgdb-error=<number> > invocation, perhaps with --track-origins=yes. And yes, this > means you are allowed to [you must] watch and help. > I don't follow. Watch and help with what? regards Tomas ------------------------------------------------------------------------------ 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 Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Tomas V. <tv...@fu...> - 2018-02-28 07:47:31
|
On 02/20/2018 02:08 PM, Nicolas Sauvaget wrote: > Tomas, > > Timers, threads ,"real time behaviour" of your application and GDB > may jostle each other, so you may not be able to use it. > Understood. Luckily, Postgres is single-threaded, and it does not use timers or realtime stuff, so that should not be a problem. > What you can do is getting a valgrind report as usual and, from this > report, understand where the issues are. Then you instrument your > code using VALGRIND_PRINTF_BACKTRACE(). Of course nothing is > automatic. > Yeah, that's where I started but it's not very practical approach. The regression tests are executing many SQL queries on many pieces of data, and it's nearly impossible to pinpoint which of the queries/rows triggers the issue based on just the report. But it seems the gdbserver with --vgdb-error=1 is very helpful, because then I can inspect the full server state and identify the exact queries / rows triggering the issue. > Hope it helps you in your investigations. > Yep, is sure did. Thanks to everyone on this thread for the help so far! And to all the devs working on valgrind - it's such a useful tool. regards Tomas |