|
From: Benn B. <be...@f5...> - 2007-07-24 19:01:45
|
Hello all -
=20
I'm trying to implement a memcheck integration for a rather complicated
application. Naturally, I'm encountering some errors probably due to my
rather limited understanding of the also limited documentation involved
with the client request mechanisms :-)
=20
Our memory topology is like so: The linux kernel is directed to use a
limited amount of the entire physical system memory at bootup. When the
application itself starts, it mmap's in the remainder using /dev/mem
into it's virtual address space. Stack space is also swapped over using
makecontext() and the entire application then proceeds to run as a
(semi)-realtime process. Actual memory management is a variation on the
Bonwick's classic slab allocator.
=20
I've added various client request macro's where I've thought
appropriate, and subsequent runs under valgrind show a disappearing
number of error messages, but there's still several problems.
=20
The first is that I don't seem to be able to get any stack traces,
though I have used the VALGRIND_STACK_REGISTER for the new uc_stack
prior to the swapcontext() call.
=20
The second is a very-very large number of the following error messages:
Conditional jump or move depends on uninitialized value(s)
Use of uninitialized value of size 4
Invalid write of size 4
=20
I can see that this is getting the debug information (the address, file,
and lineno are all populated), but I can't seem to coerce a stacktrace
for those points.
=20
It eventually gives up at the 10m mark (naturally).
=20
Now, I can entirely see that I've managed to miss pieces of the memory
allocation hierarchy, or specified them in such a fashion as to miss
pieces of memory. I'm going to, instead of running the entire
application, set up some explicit testcases for sanity and convienence.
=20
What I'm wondering about, though, is if our direct use of mmap'ed
physical memory outside of the view of the linux kernel is interfering
with memcheck's identification of valid and initialized memory
locations. This application is entirely functional in a production
environment; I have a hard time believing that all these memory
locations are truly uninitialized.
=20
Comments? Suggestions? Bonswick allocator's with valgrind macro's I
can look at as example work?
=20
Cheers,
--Benn
=20
|
|
From: Nicholas N. <nj...@cs...> - 2007-07-24 22:04:29
|
On Tue, 24 Jul 2007, Benn Bollay wrote: > Our memory topology is like so: The linux kernel is directed to use a > limited amount of the entire physical system memory at bootup. When the > application itself starts, it mmap's in the remainder using /dev/mem > into it's virtual address space. Stack space is also swapped over using > makecontext() and the entire application then proceeds to run as a > (semi)-realtime process. Actual memory management is a variation on the > Bonwick's classic slab allocator. > > [...] > > What I'm wondering about, though, is if our direct use of mmap'ed > physical memory outside of the view of the linux kernel is interfering > with memcheck's identification of valid and initialized memory > locations. It may well be. I don't know much about /dev/mem, but from what I just looked up it seems like a way for a program to access memory that's not via normal loads, stores, and syscalls like mmap. I'm pretty sure Memcheck is unaware of /dev/mem, so if memory is getting initialised via /dev/mem writes then Memcheck won't be aware of them. To do it right, Memcheck would have to check every call to read/write to see if it accesses /dev/mem, and update the memory status accordingly. That's possible, but not currently done. Nick |
|
From: Benn B. <be...@f5...> - 2007-07-24 22:31:40
|
Hi Nicholas - Once the memory is mmap'ed in, it's treated as normal virtual memory space to be allocated against. So individual pieces aren't writing against /dev/mem so much as writing against the virtual memory region mmap()'ed on top of a section of /dev/mem. So post mmap I would /think/ it would be accessed normally, just like writing to any other mmap'ed file. --Benn > -----Original Message----- > From: Nicholas Nethercote [mailto:nj...@cs...] > Sent: Tuesday, July 24, 2007 3:04 PM > To: Benn Bollay > Cc: val...@li... > Subject: Re: [Valgrind-users] Complicated custom allocator integration >=20 > On Tue, 24 Jul 2007, Benn Bollay wrote: >=20 > > Our memory topology is like so: The linux kernel is directed to use a > > limited amount of the entire physical system memory at bootup. When the > > application itself starts, it mmap's in the remainder using /dev/mem > > into it's virtual address space. Stack space is also swapped over using > > makecontext() and the entire application then proceeds to run as a > > (semi)-realtime process. Actual memory management is a variation on the > > Bonwick's classic slab allocator. > > > > [...] > > > > What I'm wondering about, though, is if our direct use of mmap'ed > > physical memory outside of the view of the linux kernel is interfering > > with memcheck's identification of valid and initialized memory > > locations. >=20 > It may well be. I don't know much about /dev/mem, but from what I just > looked up it seems like a way for a program to access memory that's not > via > normal loads, stores, and syscalls like mmap. I'm pretty sure Memcheck is > unaware of /dev/mem, so if memory is getting initialised via /dev/mem > writes > then Memcheck won't be aware of them. >=20 > To do it right, Memcheck would have to check every call to read/write to > see > if it accesses /dev/mem, and update the memory status accordingly. That's > possible, but not currently done. >=20 > Nick |
|
From: Igmar P. <mai...@jd...> - 2007-07-25 07:59:30
|
Hi, > Once the memory is mmap'ed in, it's treated as normal virtual memory > space to be allocated against. So individual pieces aren't writing > against /dev/mem so much as writing against the virtual memory region > mmap()'ed on top of a section of /dev/mem. So post mmap I would /think/ > it would be accessed normally, just like writing to any other mmap'ed > file. Is the kernel actually aware of this allocation ? I'm not quite grasping what you're trying to do, and why you choose this direction. You might want to send in a strace of a small example to let this list see what it actually does, and a valgrind -v -v output, to see if things for example show up in /proc/self/maps. Regards, Igmar |