|
From: snelling <mfy...@sn...> - 2005-04-08 15:15:23
|
When calling "times(NULL)", valgrind (2.4.22) reports: ==798== Syscall param times(buf) points to unaddressable byte(s) ==798== at 0x1BB5439D: times (in /lib/libc-2.3.2.so) ... ==798== Address 0x0 is not stack'd, malloc'd or (recently) free'd I'm using times under linux, and it appears to be valid to pass it NULL, if you are only interested in the return code (the clock ticks since boot), not the updates stored in the parameter. However, on other unix OS's (Solaris, for example), I understand this is unsafe -- you need to always pass in a pointer to a dummy "struct tms", even if you never set it or look at the contents. (It's difficult to do a web search for "times", because it's such a common word. I'm talking about TIMES(2), from "#include <sys/times.h>", with the signature "clock_t times(struct tms *buf);") I could just change our call to times to pass in a dummy struct, but I'm not sure that's really the right thing to do. I suspect that if you pass in NULL, times will optimize out collecting all the unneeded information. Should valgrind really complain about this? -- Peter Snelling |
|
From: Tom H. <to...@co...> - 2005-04-08 15:29:10
|
In message <625...@sn...>
mfy...@sn... wrote:
> When calling "times(NULL)", valgrind (2.4.22) reports:
There is no valgrind 2.4.22... I assume that is actually the
version of your kernel?
> ==798== Syscall param times(buf) points to unaddressable byte(s)
> ==798== at 0x1BB5439D: times (in /lib/libc-2.3.2.so)
> ...
> ==798== Address 0x0 is not stack'd, malloc'd or (recently) free'd
>
> I'm using times under linux, and it appears to be valid to pass it
> NULL, if you are only interested in the return code (the clock ticks
> since boot), not the updates stored in the parameter. However, on
> other unix OS's (Solaris, for example), I understand this is unsafe --
> you need to always pass in a pointer to a dummy "struct tms", even if
> you never set it or look at the contents.
You would appear to be correct - the linux manual page doesn't
actually mention allowing null but it doesn't list EFAULT as an
error either which Solaris does.
> I could just change our call to times to pass in a dummy struct, but
> I'm not sure that's really the right thing to do. I suspect that if
> you pass in NULL, times will optimize out collecting all the unneeded
> information. Should valgrind really complain about this?
The kernel does indeed optimise by skipping about two dozen lines
of code and just doing the last line ;-)
Please raise a bug for this on the bug tracker.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|