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 |