valgrind-users

[Valgrind-users] Removal of db-attach

[Maurice v. d. P. <gri...@kf...>]

I know I'm quite late with this. I only just found the information about
deprecation of --db-attach in the changelog and Florian's message about
it to this list in July of this year.

Nevertheless, I have to say that the removal of --db-attach is in my
opinion quite a step back from a usability perspective.

Valgrind has always been the one program of its kind that you could just
run on an executable that you already had and would immediately give
useful results. It has sensible defaults that keep the number of command
line options you need to specify down to a minimum.

Unfortunately the removal of --db-attach seems to make things less
convenient.

In the past I had to do the following for a simple session:
* specify a single command line option
* press n or y to continue or debug

Now I have to:
* specify a command line option
* open a second terminal
* type the full path to my executable (or navigate there) and start gdb
* type target remote | vgdb
* switch to the original terminal to check what error was given
* switch back to the gdb terminal to continue or debug

I appreciate that the built-in gdb server is an improvement over the
previous solution, but is it not possible to keep the user experience as
easy as before? If valgrind could launch gdb in the same terminal and
connect it to itself that would make the (for me) common case as easy as
it was before.

Best regards,
Maurice.

-- 
Maurice van der Pot

Kdiff3 developer   gri...@kf...   http://kdiff3.sourceforge.net
Tdiff3 developer                            https://github.com/Griffon26/tdiff3

Re: [Valgrind-users] Removal of db-attach

[Philippe W. <phi...@sk...>]

On Sat, 2015-11-28 at 18:42 +0100, Maurice van der Pot wrote:
> Unfortunately the removal of --db-attach seems to make things less
> convenient.
Yes, for simple examination of the error context of one single thread,
--db-attach=yes was easy.

I am not completely sure how straightforward it would be to launch
gdb+vgdb from valgrind itself (a.o. I am wondering about the interaction
for stdin between gdb and the application).

In the meantime, something like the below small shell script will help.
It should give the same user experience (or better, due to vgdb more
powerful functionality?).

#! /bin/sh
cat >./vgdb-hooks.gdb <<EOF
define hook-continue
  set variable \$continued_once = 1
end
define hook-stop
  if \$_thread
    if \$continued_once
      monitor v.info last_error
    end
  else
    if \$continued_once
      quit
    end
  end
end
EOF

xfce4-terminal \
   -e "gdb -ex 'source ./vgdb-hooks.gdb'
           -ex 'target remote | vgdb --wait=10'
           -ex continue  " &
valgrind --vgdb-error=0 "$@"





Some small updates might be needed, or improvements might be done:
* replace xfce4-terminal by your preferred terminal
* with valgrind 3.11 and gdb 7.10, gdb will automatically discover
  the executable being debugged. The above is based on these versions.
  Otherwise, you will have to scan the "$@" args to find the executable
  name (i.e. first argument not being a valgrind arg) and give it to
  gdb as last argument
* with the above, valgrind will always show the last error, even
  if in fact the application stops due to a break or signal or ...
  A valgrind monitor command 'v.info new_errors' could be done to only
  show the new error(s) since last request to show errors.
* you might increase --wait=10 to give enough time to valgrind to start.
  Otherwise, you could write a loop to discover the new vgdb FIFO

Philippe

Re: [Valgrind-users] Removal of db-attach

[John R. <jr...@bi...>]

On 11/29/2015 09:44 AM, Philippe Waroquiers wrote:
> On Sat, 2015-11-28 at 18:42 +0100, Maurice van der Pot wrote:
>> Unfortunately the removal of --db-attach seems to make things less
>> convenient.
> Yes, for simple examination of the error context of one single thread,
> --db-attach=yes was easy.

Very often I met bad context, wrong source line, or inability
to quit the application.  Instead, vgdb gets everything correct.
Good riddance to the demise of --db-attach.

> I am not completely sure how straightforward it would be to launch
> gdb+vgdb from valgrind itself (a.o. I am wondering about the interaction
> for stdin between gdb and the application).

Yes!  Establishing separate stdin, ctty, and process group for signals
is effectively impossible for valgrind to do by itself.  In contrast
it is trivial for the user's favorite terminal emulator environment,
such as graphical desktop, 'screen', 'tmux', etc.
Side note: copy+paste can perform all connections;
"typing" (keystrokes) can be avoided for setup if gdb is on $PATH.
Learn the keyboard commands of your terminal environment for
switching focus (keyboard and/or display).

> [[snip]]
> * with valgrind 3.11 and gdb 7.10, gdb will automatically discover
>    the executable being debugged.

gdb is likely to become confused if there is more than one candidate.
Running two sessions side-by-side for A-B comparison is common.

Re: [Valgrind-users] Removal of db-attach

[Philippe W. <phi...@sk...>]

On Sun, 2015-11-29 at 11:06 -0800, John Reiser wrote:

> > [[snip]]
> > * with valgrind 3.11 and gdb 7.10, gdb will automatically discover
> >    the executable being debugged.
> 
> gdb is likely to become confused if there is more than one candidate.
> Running two sessions side-by-side for A-B comparison is common.
Confusion should not happen, as valgrind 3.11 gdbserver reports the
executable to debug to gdb, using 'qXfer:exec-file:read' packet.

Philippe