|
From: Tomas V. <tv...@fu...> - 2018-02-19 21:27:27
|
Hi, I wonder if it's possible to generate cores (or rather vgcores) when valgrind detects invalid reads or writes. We do occasionally see such reports by valgrind, and it would be really helpful to be able to investigate the internal state using gdb. But I don't see any such option in valgrind :-( I was thinking about triggering a segfault somehow, but the trouble is I don't really know how to identify that the read actually was invalid (which is a very rare event). Adding more detailed logging is another possibility, but it's going to be very tedious to identify traces matching the invalid access. Is there a way to get core when valgrind on invalid access? Am I missing something? regards Tomas |
|
From: John R. <jr...@bi...> - 2018-02-19 22:14:28
|
> 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.
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.
|
|
From: Tomas V. <tv...@fu...> - 2018-02-20 00:50:11
|
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 |
|
From: John R. <jr...@bi...> - 2018-02-20 01:15:19
|
>> And yes, this >> means you are allowed to [you must] watch and help. > I don't follow. Watch and help with what? It means that scripting the interaction can be quirky, tedious, and frustrating. Especially the first time, you are likely to get better results by first invoking everything "by hand", then sit at the terminal, watching and waiting for the error to appear, and helping by looking at output, understanding what it means, and typing input on the keyboard. |