|
From: Tom H. <to...@co...> - 2006-09-06 17:49:27
|
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.
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
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|