|
From: smiley g. <smi...@ya...> - 2006-02-24 18:38:06
|
Hello, When a uninitialised memory error is thrown supporting information like the address of the memory, the location of the memory (stack/heap/global) name of the function's stack frame (if stack) stack trace of the allocation (if heap) name of variable (if global) will be very very helpful to debug a complex application. Looking at the source code, I could see that the error->addr is a default "0" for value_error. Is this rendered impossible because of the translation ? Thanks, Smile. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Tom H. <to...@co...> - 2006-02-24 19:18:54
|
In message <200...@we...>
smiley glitter <smi...@ya...> wrote:
> When a uninitialised memory error is thrown supporting
> information like
>
> the address of the memory,
Already shown when possible - if the uninitialised value is in
a register then obviously it has no address.
> the location of the memory (stack/heap/global)
Not something valgrind really tracks - or even something it would
be very easy for it to track definitively. The heap is particularly
problematic because it is an application level construct made by
the C library from raw memory allocations.
You can usually deduce which it is from the address anyway.
> name of the function's stack frame (if stack)
Also not particularly easy to do as it requires valgrind to assume
things about how a given program uses the stack.
Remember that valgrind has no idea if the program it is running
is written in C, Fortran, hand coded assembler or some new language
that the authors have never even heard of.
> stack trace of the allocation (if heap)
Already shown when possible.
> name of variable (if global)
Their is infrastructure in valgrind to support this but it
currently only works for stabs because nobody has written the
support for reading this information from DWARF debug information.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2006-02-25 01:42:30
|
On Fri, 24 Feb 2006, smiley glitter wrote: > When a uninitialised memory error is thrown supporting > information like > > the address of the memory, > the location of the memory (stack/heap/global) > name of the function's stack frame (if stack) > stack trace of the allocation (if heap) > name of variable (if global) > > will be very very helpful to debug a complex > application. Looking at the source code, I could see > that the error->addr is a default "0" for value_error. > Is this rendered impossible because of the translation > ? The problem is that the uninitialised value is in a register when this error is detected. To give any of the above information Memcheck would have to know what memory location the value in the register came from. This would be extra information to track for every single register value. We've thought about this but can't think of a way to do it without causing horrendous slowdowns. If anyone else can (it's more difficult than you might think) we'd like to hear about it. Nick |
|
From: smiley g. <smi...@ya...> - 2006-02-27 05:38:07
|
Hello Nick, Tom, Thanks for the response. From your recent survey there is a note that says "Almost all Valgrind use is on C and C++ programs". Though I wouldn't be happy to see Valgrind confining only to C/C++, I feel a command line option like --assume-lang=C and introducing a whole lot of goodies based on the flag will be a big value add to majority of customer base. I have been using Purify for a long time now and have benefited with the all the additional goodies I get with a UMR. The complex application that I test measured a 16x slowdown with Purify and memcheck is somewhere around 7x. I am ready to accept even a 50x slowdown for a little piece of information that will save me and the hundreds of developers I assign these bugs to, hours of debugging time. The stack trace which is usually the only thing available points to a source line with an average of 5 variables and tracking their source takes most of the time. Thanks, Smile. --- Nicholas Nethercote <nj...@cs...> wrote: > On Fri, 24 Feb 2006, smiley glitter wrote: > > > When a uninitialised memory error is thrown > supporting > > information like > > > > the address of the memory, > > the location of the memory (stack/heap/global) > > name of the function's stack frame (if stack) > > stack trace of the allocation (if heap) > > name of variable (if global) > > > > will be very very helpful to debug a complex > > application. Looking at the source code, I could > see > > that the error->addr is a default "0" for > value_error. > > Is this rendered impossible because of the > translation > > ? > > The problem is that the uninitialised value is in a > register when this error > is detected. To give any of the above information > Memcheck would have to > know what memory location the value in the register > came from. This would > be extra information to track for every single > register value. We've > thought about this but can't think of a way to do it > without causing > horrendous slowdowns. If anyone else can (it's more > difficult than you > might think) we'd like to hear about it. > > Nick > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Paul P. <ppl...@gm...> - 2006-02-27 06:05:41
|
On 2/26/06, smiley glitter <smi...@ya...> wrote:
> The complex application that I test measured a 16x
> slowdown with Purify and memcheck is somewhere around
> 7x. I am ready to accept even a 50x slowdown for a
> little piece of information that will save me and the
> hundreds of developers I assign these bugs to, hours
> of debugging time. The stack trace which is usually
> the only thing available points to a source line with
> an average of 5 variables and tracking their source
> takes most of the time.
Or you could try Insure++ which gives you exact source info ...
For example:
$ cat junk.c
typedef struct { int x[20]; } S;
int func(S *s, S *p, int i, int j)
{
return s->x[i] + p->x[j] + i + j;
}
int main()
{
S s, p;
memset(&s, 1, sizeof(s));
return func(&s, &p, 0, 0);
}
=3D=3D=3D VG =3D=3D=3D
=3D=3D7125=3D=3D Syscall param exit_group(exit_code) contains uninitialised=
byte(s)
=3D=3D7125=3D=3D at 0xA4C1A4: _Exit (in /lib/libc-2.3.5.so)
=3D=3D7125=3D=3D by 0x9D3DED: __libc_start_main (in /lib/libc-2.3.5.so)
=3D=3D=3D purify =3D=3D=3D
UMR: Uninitialized memory read:
* This is occurring while in:
func [junk.c:4]
main [junk.c:11]
__libc_start_main [libc.so.6]
_start [crt1.o]
* Reading 4 bytes from 0xbfffd9d0 on the stack.
* Address 0xbfffd9d0 is local variable "p" in function main.
=3D=3D=3D Insure++ =3D=3D=3D
[junk.c:4] **READ_UNINIT_MEM(read)**
>> return s->x[i] + p->x[j] + i + j;
Reading uninitialized memory: p->x[j]
Stack trace where the error occurred:
func() junk.c, 4
main() junk.c, 11
Cheers,
|
|
From: Nicholas N. <nj...@cs...> - 2006-02-27 09:27:19
|
On Sun, 26 Feb 2006, smiley glitter wrote: >> From your recent survey there is a note that says > "Almost all Valgrind use is on C and C++ programs". > Though I wouldn't be happy to see Valgrind confining > only to C/C++, I feel a command line option like > --assume-lang=C and introducing a whole lot of goodies > based on the flag will be a big value add to majority > of customer base. How would introducing this flag help? > I have been using Purify for a long time now and have > benefited with the all the additional goodies I get > with a UMR. If you can tell us how Purify gets the extra goodies we might have a chance of implementing them. > The complex application that I test measured a 16x > slowdown with Purify and memcheck is somewhere around > 7x. I am ready to accept even a 50x slowdown for a > little piece of information that will save me and the > hundreds of developers I assign these bugs to, hours > of debugging time. The stack trace which is usually > the only thing available points to a source line with > an average of 5 variables and tracking their source > takes most of the time. If your slow-down is only 7x you are very lucky. Typical numbers are 20--50, and Valgrind's slowness is by far the thing most people complained about in the survey. Nick |
|
From: Tom H. <to...@co...> - 2006-02-27 09:45:57
|
In message <Pin...@mu...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Sun, 26 Feb 2006, smiley glitter wrote:
>
>> "Almost all Valgrind use is on C and C++ programs".
>> Though I wouldn't be happy to see Valgrind confining
>> only to C/C++, I feel a command line option like
>> --assume-lang=C and introducing a whole lot of goodies
>> based on the flag will be a big value add to majority
>> of customer base.
>
> How would introducing this flag help?
That was aimed at my comment about how it was relatively hard to
decide whether an address was "stack", "data" or "heap" as different
languages will use memory in different ways and may not even have
those concepts and even if they do it might be hard for valgrind to
tell which is which in a general way.
>> I have been using Purify for a long time now and have
>> benefited with the all the additional goodies I get
>> with a UMR.
>
> If you can tell us how Purify gets the extra goodies we might have a
> chance of implementing them.
I suspect partly by reporting the actual read rather than the point
where the read has an effect on the program - that gets rid of the
register problem.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Duncan S. <bal...@fr...> - 2006-02-27 10:03:06
|
> > If you can tell us how Purify gets the extra goodies we might have a > > chance of implementing them. > > I suspect partly by reporting the actual read rather than the point > where the read has an effect on the program - that gets rid of the > register problem. When reading an uninitialised variable, a note could be taken of which memory location was read. When the uninitialised value is copied to another variable, the note could be copied too. If one day, maybe far far away from the initial read, the uninitialised value is used, then the note would allow you to output the location of the initial bad read. Presumably you've thought of this but rejected it because of the high overhead :) All the best, Duncan. |
|
From: smiley g. <smi...@ya...> - 2006-02-27 13:10:10
|
Hi Tom, I am not receiving your replies to my mailbox. 2 of them till now. However I see them in a different account where I have subscribed to valgrind-users. > > > > How would introducing this flag help? Yes it was aimed at Tom's comment. Hope such a flag will remove the problem of getting the information from a process in a "general way". >> >> I have been using Purify for a long time now and have >> >> benefited with the all the additional goodies I get >> >> with a UMR. I have been a user only and couldn't figure out how Purify would have implemented it. I have atleast noticed one related thing about the memory overhead aspect. Purify spawns a slave process for every process it monitors. This way it gets an additional 4G of space, which it uses to keep all of the book keeping that can be had there. gdb takes almost 20 minutes to startup with my debuggable executable which is over 1G, but Purify doesn't seem to take so much time to read everything including debug information about variables. Going over the goodies again, alongwith an UMR the address of the memory, the location of the memory (stack/heap/global) declaring function - if variable is on the stack stack trace of the allocation (if heap) name of variable (if global) and some more information like size of the original memory, amount of bytes read (memcheck has it already) offset of the read from the start of the memory (very useful again) number of bytes uninit (if its different from the number of bytes read) Thanks, Smile. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |