Hi, I've used Purify a lot before. Just curious, by any chance Valgrind supports Purify-like address->variable name translation (when -g compiled)? If so, which flag shall I set? Thanks, Julie |
|
From: Jeremy F. <je...@go...> - 2004-02-03 09:08:33
|
On Mon, 2004-02-02 at 18:23, Julie Wu wrote: > I've used Purify a lot before. Just curious, by any chance Valgrind > supports Purify-like address->variable name translation (when -g > compiled)? If so, which flag shall I set? By default Valgrind will find static or global variable names to describe an address. It will also attempt to find a C expression to describe a dynamic address, which may be on the stack or heap. It tries, but it isn't very consistently implemented. For a start, at present it only works with stabs debugging (so, compile with -gstabs) - nobody has done the work to parse the right information out of DWARF debug info yet. Also, not all messages seem to use the VG_(describe_address) function, which is what does all the work. And sometimes it just can't find an expression (there's a subtle bug which means that is sometimes uses slightly out of date information, which often doesn't work). So, more work to be done in this area. J |
Hi, Continuation on the question earlier... For uninitialized read, invalid read/write, is it possible for Valgrind to report the runtime address of the variable/memory involved? (Not necessarily with Purify-like name translation) The address reported in Valgrind log seems to be the function address in the binary. I'm trying to filter out distinct Valgrind messages. e.g., char buf[256]; -- never initialized foo(buf); bar(buf); the memory involved can be accessed in multiple routines at various locations, resulting in multiple Valgrind complaints with *different* stack traces, but they are actually all of the same error. If we have the address associated with it, then it'll be easier to group them. Thanks, Julie On Tue, 3 Feb 2004, Jeremy Fitzhardinge wrote: > On Mon, 2004-02-02 at 18:23, Julie Wu wrote: > > I've used Purify a lot before. Just curious, by any chance Valgrind > > supports Purify-like address->variable name translation (when -g > > compiled)? If so, which flag shall I set? > > By default Valgrind will find static or global variable names to > describe an address. > > It will also attempt to find a C expression to describe a dynamic > address, which may be on the stack or heap. It tries, but it isn't very > consistently implemented. For a start, at present it only works with > stabs debugging (so, compile with -gstabs) - nobody has done the work to > parse the right information out of DWARF debug info yet. Also, not all > messages seem to use the VG_(describe_address) function, which is what > does all the work. And sometimes it just can't find an expression > (there's a subtle bug which means that is sometimes uses slightly out of > date information, which often doesn't work). > > So, more work to be done in this area. > > J > > |
|
From: Nicholas N. <nj...@ca...> - 2004-02-14 17:20:20
|
On Fri, 13 Feb 2004, Julie Wu wrote: > For uninitialized read, invalid read/write, is it possible for Valgrind to > report the runtime address of the variable/memory involved? (Not > necessarily with Purify-like name translation) > [snip] > If we have the address associated with it, then it'll be easier to group > them. Yes, it would be nice to have more information about the variable causing the problem. Unfortunately, the uninitialised variable is accessed from a register at the time the error occurs. And the variable may never have been in a memory location -- for example, a compiler might put short-lived variables only in registers, and never put them into memory. And for the cases where the value has been copied from memory, it would be very difficult to track the history of the value without hurting speed badly. Given these difficulties, I don't think this will be done any time soon, unfortunately. N |
|
From: Josef W. <Jos...@gm...> - 2004-02-14 22:05:11
|
Am Saturday 14 February 2004 18:17 schrieb Nicholas Nethercote: > On Fri, 13 Feb 2004, Julie Wu wrote: > > For uninitialized read, invalid read/write, is it possible for Valgrind > > to report the runtime address of the variable/memory involved? (Not > > necessarily with Purify-like name translation) > > [snip] > > If we have the address associated with it, then it'll be easier to group > > them. > > Yes, it would be nice to have more information about the variable causing > the problem. Unfortunately, the uninitialised variable is accessed from > a register at the time the error occurs. And the variable may never have > been in a memory location -- for example, a compiler might put short-lived > variables only in registers, and never put them into memory. And for the > cases where the value has been copied from memory, it would be very > difficult to track the history of the value without hurting speed badl Perhaps I am wrong, but shouldn't debug info contain the info if a variable is mapped to a register? A debugger has to know this, too. For DWARF, some time ago I had a short look at libdwarf (from SGI). Perhaps parts can be ported to Valgrind? Josef |
My program uses 'exec'. When I set the '--logfile=vallog' option, only a
single log file is generated, and it's for the process started with the
'exec' call (i.e., cmd2). The errors prior to the 'exec' call are lost.
When I don't use the '--logfile' option, I see all the errors on 'stderr'.
int main() {
// some code with memory errors
execlp(cmd2, cmd2, 0); // start some other 'cmd2' that also contains
// memory errors
}
Is there any way to get complete log files (ideally, one for each PID)?
I've tried Valgrind version 1.9 & 2.0, not the HEAD version though.
Thanks,
Julie
|
|
From: Jeremy F. <je...@go...> - 2004-02-18 17:40:03
|
On Tue, 2004-02-17 at 18:17, Julie Wu wrote:
> My program uses 'exec'. When I set the '--logfile=vallog' option, only a
> single log file is generated, and it's for the process started with the
> 'exec' call (i.e., cmd2). The errors prior to the 'exec' call are lost.
>
> When I don't use the '--logfile' option, I see all the errors on 'stderr'.
>
> int main() {
> // some code with memory errors
>
> execlp(cmd2, cmd2, 0); // start some other 'cmd2' that also contains
> // memory errors
> }
>
> Is there any way to get complete log files (ideally, one for each PID)?
>
> I've tried Valgrind version 1.9 & 2.0, not the HEAD version though.
This has been fixed in CVS, and maybe 2.1. It now generates logfiles
with the names logfile.pidN.M, for multiple logs with the same pid.
J
|