|
From: David H. <dav...@ca...> - 2012-01-26 10:23:51
|
Hi, I'm trying to run PulseAudio under valgrind, and I think valgrind is reporting a false positive; i e, it reports "Conditional jump or move depend on uninitialised value(s)" where in fact the value seems to be perfectly initialised and correct. I've tracked it down to function snd_ctl_hw_elem_tlv in alsa-lib [1]. As you can see, if the ioctl command is SNDRV_CTL_IOCTL_TLV_READ, the kernel writes X bytes into output, where X = 4 * sizeof(unsigned int) + the number in output[3] (if output is an array of unsigned ints). I'm a little unsure of how to proceed with this? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic [1] http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/control/control_hw.c;h=1920c99a5ad3c5c34dafe7dd2c2f51bb801dea5c;hb=HEAD#l214 |
|
From: Tom H. <to...@co...> - 2012-01-26 11:28:06
|
On 26/01/12 10:23, David Henningsson wrote: > I've tracked it down to function snd_ctl_hw_elem_tlv in alsa-lib [1]. As > you can see, if the ioctl command is SNDRV_CTL_IOCTL_TLV_READ, the > kernel writes X bytes into output, where X = 4 * sizeof(unsigned int) + > the number in output[3] (if output is an array of unsigned ints). > > I'm a little unsure of how to proceed with this? You probably want to start with the README_MISSING_SYSCALL_OR_IOCTL file that you will find in the top level of the distribution. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Julian S. <js...@ac...> - 2012-01-26 11:31:36
|
On Thursday, January 26, 2012, David Henningsson wrote: > Hi, > > I'm trying to run PulseAudio under valgrind, and I think valgrind is > reporting a false positive; i e, it reports "Conditional jump or move > depend on uninitialised value(s)" where in fact the value seems to be > perfectly initialised and correct. > > I've tracked it down to function snd_ctl_hw_elem_tlv in alsa-lib [1]. As > you can see, if the ioctl command is SNDRV_CTL_IOCTL_TLV_READ, the > kernel writes X bytes into output, where X = 4 * sizeof(unsigned int) + > the number in output[3] (if output is an array of unsigned ints). > > I'm a little unsure of how to proceed with this? You need to mess with PRE(sys_ioctl) and POST(sys_ioctl) in syswrap-linux.c. The PRE wrapper needs to check that the written (by the kernel) area is addressible, using PRE_MEM_WRITE. The POST wrapper needs to mark the data written after the call using POST_MEM_WRITE. See top level README_MISSING_SYSCALL_OR_IOCTL for more details. Unfortunately both PRE(sys_ioctl) and POST(sys_ioctl) are not entirely straightforward, due to the vast number and variety of ioctls available. J |
|
From: David H. <dav...@ca...> - 2012-01-26 16:49:27
|
On 01/26/2012 12:25 PM, Julian Seward wrote: > On Thursday, January 26, 2012, David Henningsson wrote: >> Hi, >> >> I'm trying to run PulseAudio under valgrind, and I think valgrind is >> reporting a false positive; i e, it reports "Conditional jump or move >> depend on uninitialised value(s)" where in fact the value seems to be >> perfectly initialised and correct. >> >> I've tracked it down to function snd_ctl_hw_elem_tlv in alsa-lib [1]. As >> you can see, if the ioctl command is SNDRV_CTL_IOCTL_TLV_READ, the >> kernel writes X bytes into output, where X = 4 * sizeof(unsigned int) + >> the number in output[3] (if output is an array of unsigned ints). >> >> I'm a little unsure of how to proceed with this? > > You need to mess with PRE(sys_ioctl) and POST(sys_ioctl) in > syswrap-linux.c. The PRE wrapper needs to check that the > written (by the kernel) area is addressible, using PRE_MEM_WRITE. > The POST wrapper needs to mark the data written after the > call using POST_MEM_WRITE. > > See top level README_MISSING_SYSCALL_OR_IOCTL for more details. > Unfortunately both PRE(sys_ioctl) and POST(sys_ioctl) are not > entirely straightforward, due to the vast number and variety of > ioctls available. I gave this a shot, and I was finally able to write a POST(sys_ioctl), but I had to work around something strange that I could use some advice on: In the call to POST(sys_ioctl), ARG2 is a 64 bit value, which for every call except mine had the upper 32 bits set to zero. For my particular call, ARG2 was set to 0xFFFFFFFFC008551A, so it would not match my ioctl of C008551A in the following giant switch/case. Before I submit a patch for SNDRV_CTL_IOCTL_TLV_READ, I assume this needs to be generically resolved somehow? This was with the 3.7.0 release of Valgrind, btw. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic |
|
From: John R. <jr...@bi...> - 2012-01-26 18:25:04
|
On 01/26/2012 08:49 AM, David Henningsson wrote:
> In the call to POST(sys_ioctl), ARG2 is a 64 bit value, which for every
> call except mine had the upper 32 bits set to zero. For my particular
> call, ARG2 was set to 0xFFFFFFFFC008551A, so it would not match my ioctl
> of C008551A in the following giant switch/case.
> Before I submit a patch for SNDRV_CTL_IOCTL_TLV_READ, I assume this
> needs to be generically resolved somehow?
"man 2 ioctl" says that the type of the second parameter is 'int',
and thus signed:
int ioctl(int d, int request, ...);
Yet <sys/ioctl.h> says:
extern int ioctl (int __fd, unsigned long int __request, ...) __THROW;
Nearly always ARG2 is interpreted as bit fields, which are much better unsigned.
Also, an actual function prototype in <sys/ioctl.h> trumps documentation
in "man ioctl". Historically the actual interpretation of the second parameter
is "unsigned 32-bit integer". The "unsigned long" of <sys/ioctl.h>
is a hang-over from the days when 'int' was 16 bits.
However, somewhere the inconsistency affected the conversion of 'request'
from 32 to 64 bits. It's a bug which can be tedious to find.
--
|