|
From: Alex B. <ker...@be...> - 2006-09-07 09:31:51
|
On Wed, 2006-09-06 at 18:49 +0100, Tom Hughes wrote: > In message <115...@ok...> > Alex Bennee <al...@tr...> wrote: > > > I also added a client side check to the getPid() function to see if it > > was getting trampled. The output was something like: > > > > setPid tc=0x424e170 pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > ==15979== Warning: set address range perms: large range 198787072 > > (defined) > > getLock tc=0x424e170, pid=0 > > I assume you mean getpid() and not some special getPid() function of > your own? There is nothing special about the getpid system call under > valgrind so it is unlikely to be a valgrind bug. Sorry the pid mentioned in getLock is a value stored in our task structure. It is only ever set in the setPid(0 function and after that is a read only value. One option could be the variable is being overwritten by an access to some of the structures before it in our tc class. I'm guessing as Valgrind has no knowledge of the internal structure of the class it couldn't tell if being overwritten by the same sized write was a bad thing. I had a quick look at the client request mechanism and I couldn't see if there is a way to write-protect an area of memory once you know its been set and shouldn't change. I shall try adding some overflow structures in and seeing if that changes anything. > > Try adding --trace-syscalls=yes and see if the getpid system call is > really being called at that point. > > > The "set address range perms" is interestingly placed. Whats it mean? > > It means something has caused 190Mb of memory to be marked as > defined in one fell swoop. > > Tom -- Alex, homepage: http://www.bennee.com/~alex/ The hearing ear is always found close to the speaking tongue, a custom whereof the memory of man runneth not howsomever to the contrary, nohow. |