|
From: Harold N. <ha...@al...> - 2005-10-03 21:29:39
|
I'm surprised that I haven't seen discussion in the archives about the poor interaction between valgrind and gdb. The ideal workflow would be to run valgrind --db-attach=3Dyes and when it finds an error, you would enter the debugger, look at the source, make some notes, perhaps change the source, and continue on with program execution. However, valgrind does not seem to execute this scenario very well. In particular: 1) When I fire up emacs from within gdb, emacs always seems to pull up a ne= w file. For instance, if the source is /home/harold/project/module/foo.c, emacs wil= l attempt to open the file /home/harold/project/modulefoo.c. So I have to go and add the / between module and foo.c. 2) I'm not sure how you're supposed to continue execution from gdb. However= , both c (continue) or q (quit) have the same effect of never producing any response. Sometimes I get the response "Valgrind regains control", but it really doesn't at all. The program doesn't continue execution. You basically have to kill the window and start the whole process again. So you really only get to examine one valgrind error in gdb per valgrind run. Surprising I haven't seen anything discussed about this. Harold |
|
From: Harold N. <ha...@al...> - 2005-10-04 17:44:34
|
> > O, are you saying that you can not do "next" or set breakpoints and > > continue from in the debugger after the --db-attach is done.? > > If that is the case, the below point is meaningless. > It would certainly be an extremely bad idea ;-) We've always said > that you should only inspect the state and not change anything or > continue execution My model for what I'd like to see is what Purify used to do when I used it about ten years ago. You would run the program from within gdb and there was an api that allowed you to have gdb automatically stop on any type of error at any spot. Also, when stopped, you could issue purify api commands to list leaks. It also had a concept of memory color. Red meant that the memory hadn't bee= n initialized, green was allocated and initialized, etc. I forget what yellow was. But there certainly was no issue about not being able to have purify regain control. To me, if you're running valgrind, it means you want to stop if there is a problem and examine things in a debugger, and perhaps make api calls. |
|
From: Tom H. <to...@co...> - 2005-10-04 18:05:16
|
In message <bd8...@ma...>
Harold Naparst <ha...@al...> wrote:
> > > O, are you saying that you can not do "next" or set breakpoints and
> > > continue from in the debugger after the --db-attach is done.?
> > > If that is the case, the below point is meaningless.
>
> > It would certainly be an extremely bad idea ;-) We've always said
> > that you should only inspect the state and not change anything or
> > continue execution
>
> My model for what I'd like to see is what Purify used to do when I used it
> about ten years ago. You would run the program from within gdb and there
> was an api that allowed you to have gdb automatically stop on any type of
> error at any spot. Also, when stopped, you could issue purify api commands
> to list leaks.
Wasn't that exactly what I talked about in the bit of my post
that you carefully removed?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-10-04 18:06:36
|
In message <041...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <bd8...@ma...>
> Harold Naparst <ha...@al...> wrote:
>
> > > > O, are you saying that you can not do "next" or set breakpoints and
> > > > continue from in the debugger after the --db-attach is done.?
> > > > If that is the case, the below point is meaningless.
> >
> > > It would certainly be an extremely bad idea ;-) We've always said
> > > that you should only inspect the state and not change anything or
> > > continue execution
> >
> > My model for what I'd like to see is what Purify used to do when I used it
> > about ten years ago. You would run the program from within gdb and there
> > was an api that allowed you to have gdb automatically stop on any type of
> > error at any spot. Also, when stopped, you could issue purify api commands
> > to list leaks.
>
> Wasn't that exactly what I talked about in the bit of my post
> that you carefully removed?
Oh, and we do of course look forward to your patch ;-)
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Johnny <joh...@ra...> - 2005-10-04 18:44:55
|
Hello,
I want to use Valgrind to profile the memory in some C/C++ shared
libraries that are dynamically loaded by a Java VM.
Anyway, when I run our JVM with Valgrind as follows:
valgrind -v --tool=memcheck --log-file-exactly=/tmp/memcheck java ....
Does anyone know why my program always dies with the following in the
stack trace:
at
jrockit.reflect.NativeMethodInvoker.invoke0(Ljava.lang.Object;ILjava.lan
g.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
at
jrockit.reflect.NativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang
.Object;)Ljava.lang.Object;(Unknown Source)
at
java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)L
java.lang.Object;(Unknown Source)
I also get the same error when I build my own JVM with all my C/C++
libraries linked with it.
Thanks,
Johnny
|
|
From: Harold N. <ha...@al...> - 2005-10-04 23:26:20
|
> Somebody was working on a remote debugging stub or something so that > gdb would actually be controlling the simulated CPU with valgrind's > help but I have no idea what happened to that. Tom, Do you mean this part of your post? I certainly didn't intentionally remove it, but are you saying that it exists, it should exist, or it will exist, or your hoping I'll make it exist? I honestly wish I were competent to write it, but I'm barely competent to use it, and most people would doubt even that. Harold |
|
From: Tom H. <to...@co...> - 2005-10-04 23:36:00
|
In message <bd8...@ma...>
Harold Naparst <ha...@al...> wrote:
> > Somebody was working on a remote debugging stub or something so that
> > gdb would actually be controlling the simulated CPU with valgrind's
> > help but I have no idea what happened to that.
>
> Do you mean this part of your post? I certainly didn't intentionally remove
> it, but are you saying that it exists, it should exist, or it will exist,
> or your hoping I'll make it exist?
That was the bit I meant - it just shows really that this has come
up before and a solution was proposed and I believe somebody did some
work on it.
Doubtless if somebody finds this a significant enough issue then they
will spend some time working on it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
> 2) I'm not sure how you're supposed to continue execution from gdb. "detach" then "quit": ==7672== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y starting debugger ==7672== starting debugger with cmd: /usr/bin/gdb -nw /proc/7673/fd/1015 7673 [snip] Attaching to program: /proc/7673/fd/1015, process 7673 0xb0022d0d in ?? () (gdb) det Detaching from program: /proc/7673/fd/1015, process 7673 (gdb) q ==7672== ==7672== Debugger has detached. Valgrind regains control. We continue. -- |
|
From: Tom H. <to...@co...> - 2005-10-03 23:15:02
|
In message <4341B3F4.9060605@BitWagon.com>
John Reiser <jreiser@BitWagon.com> wrote:
> > 2) I'm not sure how you're supposed to continue execution from gdb.
>
> "detach" then "quit":
A simple quit has always been enough in my experience - that was
certainly the intention.
Even though I wrote the current debugger attachment code it isn't
actually something I actually use very often - hardly ever in
fact - so there might well be a problem.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
Tom Hughes wrote:
> In message <4341B3F4.9060605@BitWagon.com>
> John Reiser <jreiser@BitWagon.com> wrote:
>
>
>>>2) I'm not sure how you're supposed to continue execution from gdb.
>>
>>"detach" then "quit":
>
>
> A simple quit has always been enough in my experience - that was
> certainly the intention.
>
> Even though I wrote the current debugger attachment code it isn't
> actually something I actually use very often - hardly ever in
> fact - so there might well be a problem.
Looking carefully at the process numbers, the debugger is not dealing
with the original process itself, but with a fork(). [In the output below,
the original process is 9614, the fork is 9615, and the gdb is 9616.]
So the debugger cannot alter the state of the original process, such as
by "set var my_var = 123" Why? Running gdb on yourself works, and
with proper care can even be told to use the user's symbols, and ignore
valgrind's. See the second example below. [It might be necessary to
spoon-feed some 'add-symbol-file' commands ahead of interactive input.]
=====invoking gdb from valgrind(memcheck); note 3 processes: vg, vg.fork(), gdb.
==9614== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
starting debugger
==9614== starting debugger with cmd: /usr/bin/gdb -nw /proc/9615/fd/1015 9615
[gdb banner snipped]
Attaching to program: /proc/9615/fd/1015, process 9615
0xb0022d0d in ?? ()
(gdb) shell
[user@host ~]$ ps l
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 500 2561 2542 15 0 4512 1500 wait Ss pts/0 0:00 bash
0 500 9614 2561 16 0 1557980 8608 wait S pts/0 0:00 valgrind301
--db-attach=yes ./uninit
0 500 9616 9614 15 0 6972 2784 wait S pts/0 0:00 /usr/bin/gdb -nw
/proc/9615/fd/1015 9615
1 500 9615 9614 17 0 1557980 8612 finish T pts/0 0:00 valgrind301
--db-attach=yes ./uninit
0 500 9619 9616 15 0 4512 1488 wait S pts/0 0:00 bash
0 500 9639 9619 16 0 4440 812 - R+ pts/0 0:00 ps l
$
=====
=====invoking gdb on yourself
$ cat gdbself.c
#include <stdio.h>
#include <unistd.h>
int x;
char cmd[100];
main(int argc, char *argv[])
{
printf("x=%d\n", x);
sprintf(cmd, "gdb %s %d\n", argv[0], getpid());
printf("%s\n", cmd);
system(cmd);
printf("x=%d\n", x);
return 0;
}
$ gcc -g -o gdbself gdbself.c
$ ./gdbself
x=0 ## note original value
gdb ./gdbself 9797
[gdb banner snipped]
Attaching to program: ./gdbself, process 9797
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x001c9402 in ?? ()
(gdb) shell
$ ps l
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 500 9619 2542 16 0 4516 1488 - Ss+ pts/1 0:00 bash
0 500 9798 9797 15 0 8736 4468 wait S pts/0 0:00 gdb ./gdbself 9797
0 500 9797 9619 16 0 1412 344 ptrace T pts/0 0:00 ./gdbself
0 500 9803 9798 15 0 4516 1492 wait S pts/0 0:00 bash
0 500 9823 9803 16 0 4444 812 - R+ pts/0 0:00 ps l
$ exit
(gdb) set var x = 123 ## change value in debugger
(gdb) q
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: ./gdbself, process 9797
x=123 ## note that the value got changed
$
=====
--
|
|
From: Tom H. <to...@co...> - 2005-10-04 08:27:57
|
In message <4341F283.6030600@BitWagon.com>
John Reiser <jreiser@BitWagon.com> wrote:
> Tom Hughes wrote:
>> In message <4341B3F4.9060605@BitWagon.com>
>> John Reiser <jreiser@BitWagon.com> wrote:
>>
>>
>>>>2) I'm not sure how you're supposed to continue execution from gdb.
>>>
>>>"detach" then "quit":
>>
>>
>> A simple quit has always been enough in my experience - that was
>> certainly the intention.
>>
>> Even though I wrote the current debugger attachment code it isn't
>> actually something I actually use very often - hardly ever in
>> fact - so there might well be a problem.
>
> Looking carefully at the process numbers, the debugger is not dealing
> with the original process itself, but with a fork(). [In the output below,
> the original process is 9614, the fork is 9615, and the gdb is 9616.]
> So the debugger cannot alter the state of the original process, such as
> by "set var my_var = 123" Why? Running gdb on yourself works, and
> with proper care can even be told to use the user's symbols, and ignore
> valgrind's. See the second example below. [It might be necessary to
> spoon-feed some 'add-symbol-file' commands ahead of interactive input.]
The reason we fork a copy of the process is that we want the debugger
to see the simulated register set rather than the real register set.
So we fork a copy then use ptrace to change that copy's registers to
hold the simulated registers and then attach a debugger to the copy
and wait for the debugger to finish. When the debugger is done we
make sure the copy is dead and then carry on.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bob R. <bo...@br...> - 2005-10-04 12:01:24
|
On Tue, Oct 04, 2005 at 09:27:46AM +0100, Tom Hughes wrote: > In message <4341F283.6030600@BitWagon.com> > John Reiser <jreiser@BitWagon.com> wrote: > > > Tom Hughes wrote: > >> In message <4341B3F4.9060605@BitWagon.com> > >> John Reiser <jreiser@BitWagon.com> wrote: > >> > >> > >>>>2) I'm not sure how you're supposed to continue execution from gdb. > >>> > >>>"detach" then "quit": > >> > >> > >> A simple quit has always been enough in my experience - that was > >> certainly the intention. > >> > >> Even though I wrote the current debugger attachment code it isn't > >> actually something I actually use very often - hardly ever in > >> fact - so there might well be a problem. > > > > Looking carefully at the process numbers, the debugger is not dealing > > with the original process itself, but with a fork(). [In the output below, > > the original process is 9614, the fork is 9615, and the gdb is 9616.] > > So the debugger cannot alter the state of the original process, such as > > by "set var my_var = 123" Why? Running gdb on yourself works, and > > with proper care can even be told to use the user's symbols, and ignore > > valgrind's. See the second example below. [It might be necessary to > > spoon-feed some 'add-symbol-file' commands ahead of interactive input.] > > The reason we fork a copy of the process is that we want the debugger > to see the simulated register set rather than the real register set. > > So we fork a copy then use ptrace to change that copy's registers to > hold the simulated registers and then attach a debugger to the copy > and wait for the debugger to finish. When the debugger is done we > make sure the copy is dead and then carry on. This works most of the time, of course. However, if your program changes the state of something external (filesystem, network sockets, ...), then when you "carry on", something could potentially hit the fan. In this situation, the best bet is to fix the problem and restart. Bob Rossi |
|
From: Tom H. <to...@co...> - 2005-10-04 12:15:07
|
In message <20051004120104.GA1236@white>
Bob Rossi <bo...@br...> wrote:
> This works most of the time, of course. However, if your program changes
> the state of something external (filesystem, network sockets, ...), then
> when you "carry on", something could potentially hit the fan. In this
> situation, the best bet is to fix the problem and restart.
Which program? The valgrind client is suspended as is the copy of it
that is being debugged.
Obviously the user can use a shell to do something horrible while we
are in the debugger but that is always true even if you're not in the
debugger.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bob R. <bo...@br...> - 2005-10-04 13:07:30
|
On Tue, Oct 04, 2005 at 01:14:54PM +0100, Tom Hughes wrote: > In message <20051004120104.GA1236@white> > Bob Rossi <bo...@br...> wrote: > > > This works most of the time, of course. However, if your program changes > > the state of something external (filesystem, network sockets, ...), then > > when you "carry on", something could potentially hit the fan. In this > > situation, the best bet is to fix the problem and restart. > > Which program? The valgrind client is suspended as is the copy of it > that is being debugged. O, are you saying that you can not do "next" or set breakpoints and continue from in the debugger after the --db-attach is done.? If that is the case, the below point is meaningless. > Obviously the user can use a shell to do something horrible while we > are in the debugger but that is always true even if you're not in the > debugger. Correct. However, what if valgrind finds a bug directly before a write system call to a network socket. This is the point at which valgrind attaches the debugger to the forked process. I'm assuming the user does at least a "next" over the "write" system call. For a simple example, the network packet is read on the other side, it brews a pot of coffee and returns some packets telling the program being debugged that a pot of coffee was jot brewed. When you 'quit' out of GDB, and continue on from where you left off, the network packet is sent again. This time, the other side receives the packet again, but returns a different message. "Coffee is already made." So, what I was trying to say with my original statement is that if you are allowed to manipulate external forces, the second time you step through the code, the results could be different. Does this sound correct? I was simply trying to point out a caveat of using this feature. I happen to use this functionality all the time, but always restart after doing it. Thanks, Bob Rossi |
|
From: Tom H. <to...@co...> - 2005-10-04 13:21:23
|
In message <20051004130708.GA1387@white>
Bob Rossi <bo...@br...> wrote:
> On Tue, Oct 04, 2005 at 01:14:54PM +0100, Tom Hughes wrote:
>> In message <20051004120104.GA1236@white>
>> Bob Rossi <bo...@br...> wrote:
>>
>> > This works most of the time, of course. However, if your program changes
>> > the state of something external (filesystem, network sockets, ...), then
>> > when you "carry on", something could potentially hit the fan. In this
>> > situation, the best bet is to fix the problem and restart.
>>
>> Which program? The valgrind client is suspended as is the copy of it
>> that is being debugged.
>
> O, are you saying that you can not do "next" or set breakpoints and
> continue from in the debugger after the --db-attach is done.?
> If that is the case, the below point is meaningless.
It would certainly be an extremely bad idea ;-) We've always said
that you should only inspect the state and not change anything or
continue execution.
Somebody was working on a remote debugging stub or something so that
gdb would actually be controlling the simulated CPU with valgrind's
help but I have no idea what happened to that.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|