|
From: Paul W. <pa...@bl...> - 2006-03-26 21:40:22
|
Hi all, I've been trying to confirm whether something's a bug or not in a program which uses ncurses (mutt). I was trying to get valgrind to automatically attach gdb when it spots the overrunning read - however, since mutt starts up ncurses, that interferes with valgrind's input. I wrote a small wrapper program which accepts a telnet connection and then forks valgrind, using the telnet connection for valgrind i/o. That seems to work, except when it comes to starting gdb - there's no sign of it starting at all. What does the gdb process that valgrind spawns use as it's stdin and stdout? Are they dup'ed from the input-fd and log-fd, or the program's stdin/stdout? I noticed various messages (at User level) in valgrind which might at least confirm whether gdb is being started or not, but I can't seem to work out how to turn those on... Any offers...? Thanks all, -- Paul |
|
From: Julian S. <js...@ac...> - 2006-03-26 21:57:18
|
Hi Without understanding all the ins and outs of this .. can you get any mileage out of the --input-fd= flag? J On Sunday 26 March 2006 22:40, Paul Walker wrote: > Hi all, > > I've been trying to confirm whether something's a bug or not in a program > which uses ncurses (mutt). I was trying to get valgrind to automatically > attach gdb when it spots the overrunning read - however, since mutt starts > up ncurses, that interferes with valgrind's input. > > I wrote a small wrapper program which accepts a telnet connection and then > forks valgrind, using the telnet connection for valgrind i/o. That seems to > work, except when it comes to starting gdb - there's no sign of it starting > at all. > > What does the gdb process that valgrind spawns use as it's stdin and > stdout? Are they dup'ed from the input-fd and log-fd, or the program's > stdin/stdout? > > I noticed various messages (at User level) in valgrind which might at least > confirm whether gdb is being started or not, but I can't seem to work out > how to turn those on... > > Any offers...? > > Thanks all, |
|
From: Paul W. <pa...@bl...> - 2006-03-26 22:06:21
|
On Sun, Mar 26, 2006 at 10:57:00PM +0100, Julian Seward wrote:
> Without understanding all the ins and outs of this .. can you
> get any mileage out of the --input-fd= flag?
Sorry, I think I wasn't clear - I'm already using the input-fd and log-fd
descriptors for valgrind input/output, and they're most useful.
Since asking the question, I've even found a script from someone which pops
up a new xterm with gdb loaded, but it never seems to fire. Maybe the 'y' is
getting eaten somewhere en-route... this would seem to make it my problem
rather than anything else, though.
Don't suppose you remember how I can get valgrind to output this line?
[m_debugger.c]
VG_(message)(Vg_UserMsg, "starting debugger with cmd: %s", buf);
Just adding more -v options doesn't seem to have done it, unfortunately.
Cheers,
--
Paul
A debugged program is one for which you have not yet found the conditions
that make it fail. -- Jerry Ogdin
|
|
From: Nicholas N. <nj...@cs...> - 2006-03-26 22:56:38
|
On Sun, 26 Mar 2006, Paul Walker wrote: > Don't suppose you remember how I can get valgrind to output this line? > > [m_debugger.c] > VG_(message)(Vg_UserMsg, "starting debugger with cmd: %s", buf); > > Just adding more -v options doesn't seem to have done it, unfortunately. It should always (unless you specify -q, I think) print that out when starting the debugger. If it doesn't, that means one of the pre-startup tests is failing. Sprinkling some debugging printfs around VG_(start_debugger)() might be informative. Nick |
|
From: Tom H. <to...@co...> - 2006-03-26 22:59:45
|
In message <200...@bl...>
Paul Walker <pa...@bl...> wrote:
> On Sun, Mar 26, 2006 at 10:57:00PM +0100, Julian Seward wrote:
>
> > Without understanding all the ins and outs of this .. can you
> > get any mileage out of the --input-fd= flag?
>
> Sorry, I think I wasn't clear - I'm already using the input-fd and log-fd
> descriptors for valgrind input/output, and they're most useful.
>
> Since asking the question, I've even found a script from someone which pops
> up a new xterm with gdb loaded, but it never seems to fire. Maybe the 'y' is
> getting eaten somewhere en-route... this would seem to make it my problem
> rather than anything else, though.
If you're using curses and typing 'y' doesn't appear to work then
you are probably in raw mode and the return key is not doing what
valgrind expects. Try typing ctrl-J and/or ctrl-M after the y.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul W. <pa...@bl...> - 2006-03-26 23:54:45
|
On Sun, Mar 26, 2006 at 11:59:38PM +0100, Tom Hughes wrote: > If you're using curses and typing 'y' doesn't appear to work then > you are probably in raw mode and the return key is not doing what > valgrind expects. Try typing ctrl-J and/or ctrl-M after the y. It was receiving enter okay, but abandoning the telnet idea and hitting y lots of times along with what you mentioned above did eventually coax it into spawning gdb, albeit with a very scrambled display. Thankfully, this seems to have confirmed what I thought - the "Invalid read of 4 bytes" is actually glibc doing a strchr as it does a dlopen. :-) So mutt's in the clear for now. I think I'll try and work out why the telnet thing wasn't work anyway, though; it might be useful. Thanks to both you and Nick :) -- Paul |
|
From: Bob R. <bob...@co...> - 2006-03-27 02:27:05
|
On Sun, Mar 26, 2006 at 10:57:00PM +0100, Julian Seward wrote: > > Hi > > Without understanding all the ins and outs of this .. can you > get any mileage out of the --input-fd= flag? > Yeah, Julian helped me with this a while ago. I use valgrind with CGDB (curses based interface to GNU debugger) all the time now. Here's what I do. valgrind --tool=memcheck --num-callers=30 --gen-suppressions=no --log-fd=50 ./cgdb ./test 50>out.txt where, cgdb is the program I am having valgrind run, and ./test is an argument to cgdb. This will give me all the error's that valgrind found, although it's not interactive. Bob Rossi |