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
------------------------------------------------------------------------------
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
