|
From: Jon S. <jps...@mt...> - 2007-04-24 20:25:02
|
I'm working with the raw1394 and dc1394 libraries on Linux and the raw1394 library does something pretty nasty with memory. It converts a pointer into an int and writes it to a device node and then the kernel driver stuffs data into that memory address and sends a message back on the device. Of course valgrind complains that the memory that comes back is not initialized. Is there a way to tell valgrind to just trust that the memory passed to that function gets populated correctly? I looked at creating supression filters, but since it's on the read call, not the write call, checking each stack trace takes lots of time. Thanks. ________________________________________________________________________ Jon Schewe | http://www.mtu.net/~jpschewe Help Jen and I fight cancer by donating to the Leukemia & Lymphomia Society Here's our website: http://www.active.com/tntmn/tntmnJSchewe |
|
From: Nicholas N. <nj...@cs...> - 2007-04-24 23:20:11
|
On Tue, 24 Apr 2007, Jon Schewe wrote: > I'm working with the raw1394 and dc1394 libraries on Linux and the > raw1394 library does something pretty nasty with memory. It converts a > pointer into an int and writes it to a device node and then the kernel > driver stuffs data into that memory address and sends a message back on > the device. Of course valgrind complains that the memory that comes > back is not initialized. Is there a way to tell valgrind to just trust > that the memory passed to that function gets populated correctly? I > looked at creating supression filters, but since it's on the read call, > not the write call, checking each stack trace takes lots of time. What is happening exactly in terms of system calls? That's what Memcheck looks at. For example, after a read() syscall, it will mark the number of read bytes as initialized. Nick |
|
From: Jon S. <jps...@mt...> - 2007-04-25 03:27:24
|
On Wed, 2007-04-25 at 09:20 +1000, Nicholas Nethercote wrote:
> On Tue, 24 Apr 2007, Jon Schewe wrote:
>=20
> > I'm working with the raw1394 and dc1394 libraries on Linux and the
> > raw1394 library does something pretty nasty with memory. It converts a
> > pointer into an int and writes it to a device node and then the kernel
> > driver stuffs data into that memory address and sends a message back on
> > the device. Of course valgrind complains that the memory that comes
> > back is not initialized. Is there a way to tell valgrind to just trust
> > that the memory passed to that function gets populated correctly? I
> > looked at creating supression filters, but since it's on the read call,
> > not the write call, checking each stack trace takes lots of time.
>=20
> What is happening exactly in terms of system calls? That's what Memcheck=
=20
> looks at. For example, after a read() syscall, it will mark the number of=
=20
> read bytes as initialized.
There is a write system call that writes out a struct something like
this (I can't remember it offhand):
struct {
unsigned int operation;
unsigned int address; // really a pointer converted using ptrtoint
}
Inside the kernel, address is converted back to a pointer and data is
written to that address. The application is then notified of the
written data by doing a read call that gets the return status of the
call. Now valgrind states that the memory at address is uninitialized,
even though the kernel wrote perfectly valid values there. See
drivers/ieee1394/raw1394.c raw1394_read and pay attention to recvb.
So an example call would be something like this:
char buffer[256];
struct pending_request data { 1, buffer }
write(fd, data);
char retval[16];
read(fd, retval);
if( success ) {
Use buffer which causes a valgrind error. Even doing a memset of buffer
before calling write doesn't help.
}
________________________________________________________________________
Jon Schewe | http://mtu.net/~jpschewe
Help Jen and I fight cancer by donating to the Leukemia & Lymphomia
Society
Here's our website: http://www.active.com/donate/tntmn/tntmnJSchewe
If you see an attachment named signature.asc, this is my digital
signature.
See http://www.gnupg.org for more information.
|
|
From: Tom H. <to...@co...> - 2007-04-25 07:27:26
|
In message <117...@jo...>
Jon Schewe <jps...@mt...> wrote:
> There is a write system call that writes out a struct something like
> this (I can't remember it offhand):
> struct {
> unsigned int operation;
> unsigned int address; // really a pointer converted using ptrtoint
> }
>
> Inside the kernel, address is converted back to a pointer and data is
> written to that address. The application is then notified of the
> written data by doing a read call that gets the return status of the
> call. Now valgrind states that the memory at address is uninitialized,
> even though the kernel wrote perfectly valid values there. See
> drivers/ieee1394/raw1394.c raw1394_read and pay attention to recvb.
Oh that is just disgusting! Hadn't they ever heard of ioctl...
That's more or less impossible to fix in valgrind as it has no way
to know that the file descriptor you are writing to corresponds to
an IEEE1394 device.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jon S. <jps...@mt...> - 2007-04-25 10:09:34
|
On Wed, 2007-04-25 at 08:27 +0100, Tom Hughes wrote:
> In message <117...@jo...>
> Jon Schewe <jps...@mt...> wrote:
>=20
> > There is a write system call that writes out a struct something like
> > this (I can't remember it offhand):
> > struct {
> > unsigned int operation;
> > unsigned int address; // really a pointer converted using ptrtoint
> > }
> >
> > Inside the kernel, address is converted back to a pointer and data is
> > written to that address. The application is then notified of the
> > written data by doing a read call that gets the return status of the
> > call. Now valgrind states that the memory at address is uninitialized,
> > even though the kernel wrote perfectly valid values there. See
> > drivers/ieee1394/raw1394.c raw1394_read and pay attention to recvb.
>=20
> Oh that is just disgusting! Hadn't they ever heard of ioctl...
>=20
It's how they're doing DMA transfers. All of the setup is done via
ioctl=20
> That's more or less impossible to fix in valgrind as it has no way
> to know that the file descriptor you are writing to corresponds to
> an IEEE1394 device.
I was afraid of that. There is a function in the raw1394 library that
the memory always passes through first. Is there a way to tell valgrind
that when memory passes through this function, just set the valid bits
even though valgrind can't track it all of the way?
________________________________________________________________________
Jon Schewe | http://mtu.net/~jpschewe
Help Jen and I fight cancer by donating to the Leukemia & Lymphomia
Society
Here's our website: http://www.active.com/donate/tntmn/tntmnJSchewe
If you see an attachment named signature.asc, this is my digital
signature.
See http://www.gnupg.org for more information.
|
|
From: Ashley P. <as...@qu...> - 2007-04-25 10:18:47
|
On Wed, 2007-04-25 at 05:09 -0500, Jon Schewe wrote: > > That's more or less impossible to fix in valgrind as it has no way > > to know that the file descriptor you are writing to corresponds to > > an IEEE1394 device. > > I was afraid of that. There is a function in the raw1394 library that > the memory always passes through first. Is there a way to tell valgrind > that when memory passes through this function, just set the valid bits > even though valgrind can't track it all of the way? Yes, it sounds like you need to annotate the code in the library with calls to the VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE() and VALGRIND_CHECK_MEM_IS_DEFINED() macros from valgrind/memcheck.h We do this in our code where we hardware DMAs directly to userspace and it works very well. Ashley. |
|
From: Jon S. <jps...@mt...> - 2007-04-25 10:26:13
|
On Wed, 2007-04-25 at 11:15 +0100, Ashley Pittman wrote: > On Wed, 2007-04-25 at 05:09 -0500, Jon Schewe wrote: > > > That's more or less impossible to fix in valgrind as it has no way > > > to know that the file descriptor you are writing to corresponds to > > > an IEEE1394 device. > >=20 > > I was afraid of that. There is a function in the raw1394 library that > > the memory always passes through first. Is there a way to tell valgrin= d > > that when memory passes through this function, just set the valid bits > > even though valgrind can't track it all of the way? >=20 > Yes, it sounds like you need to annotate the code in the library with > calls to the VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE() and > VALGRIND_CHECK_MEM_IS_DEFINED() macros from valgrind/memcheck.h >=20 > We do this in our code where we hardware DMAs directly to userspace and > it works very well. This sounds very promising. Where might there be some examples of this? Does this mean you make your code depend upon valgrind/memcheck.h? How do you handle distribution? ________________________________________________________________________ Jon Schewe | http://mtu.net/~jpschewe Help Jen and I fight cancer by donating to the Leukemia & Lymphomia Society Here's our website: http://www.active.com/donate/tntmn/tntmnJSchewe If you see an attachment named signature.asc, this is my digital signature. See http://www.gnupg.org for more information. |
|
From: Ashley P. <as...@qu...> - 2007-04-25 10:44:52
|
On Wed, 2007-04-25 at 05:26 -0500, Jon Schewe wrote: > On Wed, 2007-04-25 at 11:15 +0100, Ashley Pittman wrote: > > On Wed, 2007-04-25 at 05:09 -0500, Jon Schewe wrote: > > > > That's more or less impossible to fix in valgrind as it has no way > > > > to know that the file descriptor you are writing to corresponds to > > > > an IEEE1394 device. > > > > > > I was afraid of that. There is a function in the raw1394 library that > > > the memory always passes through first. Is there a way to tell valgrind > > > that when memory passes through this function, just set the valid bits > > > even though valgrind can't track it all of the way? > > > > Yes, it sounds like you need to annotate the code in the library with > > calls to the VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE() and > > VALGRIND_CHECK_MEM_IS_DEFINED() macros from valgrind/memcheck.h > > > > We do this in our code where we hardware DMAs directly to userspace and > > it works very well. > > This sounds very promising. Where might there be some examples of this? Have a look at mpiwrap.c in the valgrind source for one place where they are used, there is fairly good documentation in the header file itself. > Does this mean you make your code depend upon valgrind/memcheck.h? How > do you handle distribution? Yes but that's what the header file is there for, if valgrind is installed you should have the header file as well. Ashley, |
|
From: Jon S. <jps...@mt...> - 2007-04-25 10:51:12
|
On Wed, 2007-04-25 at 11:35 +0100, Ashley Pittman wrote: > > Does this mean you make your code depend upon valgrind/memcheck.h? How > > do you handle distribution? >=20 > Yes but that's what the header file is there for, if valgrind is > installed you should have the header file as well. Are there any problems with it being both included with the application and on the system? The situation being that the application shouldn't require valgrind on the system to be built, but should do the right thing when valgrind is present. ________________________________________________________________________ Jon Schewe | http://mtu.net/~jpschewe Help Jen and I fight cancer by donating to the Leukemia & Lymphomia Society Here's our website: http://www.active.com/donate/tntmn/tntmnJSchewe If you see an attachment named signature.asc, this is my digital signature. See http://www.gnupg.org for more information. |
|
From: Ashley P. <as...@qu...> - 2007-04-25 11:09:01
|
On Wed, 2007-04-25 at 05:51 -0500, Jon Schewe wrote: > On Wed, 2007-04-25 at 11:35 +0100, Ashley Pittman wrote: > > > Does this mean you make your code depend upon valgrind/memcheck.h? How > > > do you handle distribution? > > > > Yes but that's what the header file is there for, if valgrind is > > installed you should have the header file as well. > > Are there any problems with it being both included with the application > and on the system? The situation being that the application shouldn't > require valgrind on the system to be built, but should do the right > thing when valgrind is present. If you compile your code with the macros in then the application will still run normally if not running under valgrind, they use a magic sequence of instructions (shifts IIRC) that no same piece of code would ever do and are recognised by valgrind at run-time. Here we have copied the header files (you need valgrind.h and memcheck.h) to our source tree and ship them as part of the source tarball, this isn't recommended however, you could maybe use a autoconf test to see if they are avaliable at compile time? We ship a "normal" and "debug" version of our library anyway and only compile in the code in the debug library, you will know what is going to work best for you. Be aware that compatibility was broken somewhere in the 2.x line so older versions of the header files have no effect on newer versions of valgrind. Ashley, |
|
From: Jon S. <jps...@mt...> - 2007-04-26 17:34:18
|
On Wed, 2007-04-25 at 12:01 +0100, Ashley Pittman wrote: > Be aware that compatibility was broken somewhere in the 2.x line so > older versions of the header files have no effect on newer versions of > valgrind. How do you deal with older versions of valgrind? ________________________________________________________________________ Jon Schewe | http://www.mtu.net/~jpschewe Help Jen and I fight cancer by donating to the Leukemia & Lymphomia Society Here's our website: http://www.active.com/tntmn/tntmnJSchewe |
|
From: Ashley P. <as...@qu...> - 2007-04-27 10:53:52
|
On Thu, 2007-04-26 at 12:34 -0500, Jon Schewe wrote: > On Wed, 2007-04-25 at 12:01 +0100, Ashley Pittman wrote: > > Be aware that compatibility was broken somewhere in the 2.x line so > > older versions of the header files have no effect on newer versions of > > valgrind. > > How do you deal with older versions of valgrind? If you use an older version of valgrind the annotations have no effect, it's the same as not having any annotations so you typically get false positives. Ashley, |
|
From: Jon S. <jps...@mt...> - 2007-04-27 11:10:55
|
On Fri, 2007-04-27 at 11:53 +0100, Ashley Pittman wrote:
> On Thu, 2007-04-26 at 12:34 -0500, Jon Schewe wrote:
> > On Wed, 2007-04-25 at 12:01 +0100, Ashley Pittman wrote:
> > > Be aware that compatibility was broken somewhere in the 2.x line so
> > > older versions of the header files have no effect on newer versions of
> > > valgrind.
> >
> > How do you deal with older versions of valgrind?
>
> If you use an older version of valgrind the annotations have no effect,
> it's the same as not having any annotations so you typically get false
> positives.
Do the annotations exist in previous versions of the headers? I'm doing
an autoconf script to check for valgrind/memcheck.h and that defines
HAVE_VALGRIND_MEMCHECK_H to be 1 if it's found on the system. So if I
have the following in my code, does it seem right?
#if HAVE_VALGRIND_MEMCHECK_H
# include <valgrind/memcheck.h>
# ifndef VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE
# define VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE do {} while(0)
# endif
#else
# define VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE do {} while(0)
#endif
Thanks for all of your help.
________________________________________________________________________
Jon Schewe | http://mtu.net/~jpschewe
Help Jen and I fight cancer by donating to the Leukemia & Lymphomia
Society
Here's our website: http://www.active.com/donate/tntmn/tntmnJSchewe
If you see an attachment named signature.asc, this is my digital
signature.
See http://www.gnupg.org for more information.
|
|
From: Shruthi G. <sgo...@ya...> - 2007-04-27 11:44:05
|
Hi,
Just one hour back I started seeing Valgrind. Am not sure if Valgrind supports mips. Can I cross compile with mipsel-gcc and make it work on mips...??
Sorry for a silly question.
Thanks in Advance.
Regards,
S
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
Check outnew cars at Yahoo! Autos. |
|
From: Tom H. <to...@co...> - 2007-04-27 12:36:28
|
In message <766...@we...>
Shruthi Gonchkar <sgo...@ya...> wrote:
> Just one hour back I started seeing Valgrind. Am not sure if
> Valgrind supports mips. Can I cross compile with mipsel-gcc and
> make it work on mips...??
No, it doesn't support MIPS I'm afraid.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul W. <pa...@bl...> - 2007-04-27 12:38:51
|
Hi, > Just one hour back I started seeing Valgrind. Am not sure if Valgrind > supports mips. Can I cross compile with mipsel-gcc and make it work on > mips...?? This is covered on the valgrind website. :-) http://valgrind.org/info/platforms.html The supported platforms at the moment are x86, AMD64, and PPC32/64. Though if you want to port it to MIPS, I'd be grateful... -- Paul If all the salmon caught in Canada in one year were laid end to end across the Sahara Desert, the smell would be absolutely awful. |
|
From: Ashley P. <as...@qu...> - 2007-04-27 11:19:50
|
On Fri, 2007-04-27 at 06:10 -0500, Jon Schewe wrote:
> On Fri, 2007-04-27 at 11:53 +0100, Ashley Pittman wrote:
> > On Thu, 2007-04-26 at 12:34 -0500, Jon Schewe wrote:
> > > On Wed, 2007-04-25 at 12:01 +0100, Ashley Pittman wrote:
> > > > Be aware that compatibility was broken somewhere in the 2.x line so
> > > > older versions of the header files have no effect on newer versions of
> > > > valgrind.
> > >
> > > How do you deal with older versions of valgrind?
> >
> > If you use an older version of valgrind the annotations have no effect,
> > it's the same as not having any annotations so you typically get false
> > positives.
>
> Do the annotations exist in previous versions of the headers? I'm doing
> an autoconf script to check for valgrind/memcheck.h and that defines
> HAVE_VALGRIND_MEMCHECK_H to be 1 if it's found on the system. So if I
> have the following in my code, does it seem right?
>
> #if HAVE_VALGRIND_MEMCHECK_H
> # include <valgrind/memcheck.h>
> # ifndef VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE
> # define VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE do {} while(0)
> # endif
> #else
> # define VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE do {} while(0)
> #endif
I think you need to put valgrind/valgrind.h before valgrind/memcheck.h.
The names of the macros have changed at some point as well, the
MAKE_DEFINED_IF_ADDRESSABLE() is a addition in the last year or so,
older releases just had MAKE_DEFINED() which has the potential to do bad
things if you call it on addressable memory.
Ashley,
|
|
From: Jon S. <jps...@mt...> - 2007-04-27 11:40:38
|
On Fri, 2007-04-27 at 12:18 +0100, Ashley Pittman wrote:
> On Fri, 2007-04-27 at 06:10 -0500, Jon Schewe wrote:
> > On Fri, 2007-04-27 at 11:53 +0100, Ashley Pittman wrote:
> > > On Thu, 2007-04-26 at 12:34 -0500, Jon Schewe wrote:
> > > > On Wed, 2007-04-25 at 12:01 +0100, Ashley Pittman wrote:
> > > > > Be aware that compatibility was broken somewhere in the 2.x line so
> > > > > older versions of the header files have no effect on newer versions of
> > > > > valgrind.
> > > >
> > > > How do you deal with older versions of valgrind?
> > >
> > > If you use an older version of valgrind the annotations have no effect,
> > > it's the same as not having any annotations so you typically get false
> > > positives.
> >
> > Do the annotations exist in previous versions of the headers? I'm doing
> > an autoconf script to check for valgrind/memcheck.h and that defines
> > HAVE_VALGRIND_MEMCHECK_H to be 1 if it's found on the system. So if I
> > have the following in my code, does it seem right?
> >
> > #if HAVE_VALGRIND_MEMCHECK_H
> > # include <valgrind/memcheck.h>
> > # ifndef VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE
> > # define VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE do {} while(0)
> > # endif
> > #else
> > # define VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE do {} while(0)
> > #endif
>
> I think you need to put valgrind/valgrind.h before valgrind/memcheck.h.
>
> The names of the macros have changed at some point as well, the
> MAKE_DEFINED_IF_ADDRESSABLE() is a addition in the last year or so,
> older releases just had MAKE_DEFINED() which has the potential to do bad
> things if you call it on addressable memory.
memcheck.h includes valgrind.h, so only one is required. It sounds like
my ifndef check is also correct given your statement about when the
macros were defined.
________________________________________________________________________
Jon Schewe | http://mtu.net/~jpschewe
Help Jen and I fight cancer by donating to the Leukemia & Lymphomia
Society
Here's our website: http://www.active.com/donate/tntmn/tntmnJSchewe
If you see an attachment named signature.asc, this is my digital
signature.
See http://www.gnupg.org for more information.
|