[alsa-devel] snd_seq_parse_address accesses uninitialised data
tiwai at suse.de
Mon Sep 24 17:46:28 CEST 2012
At Mon, 24 Sep 2012 16:20:50 +0200 (CEST),
Henning Thielemann wrote:
> On Mon, 24 Sep 2012, Takashi Iwai wrote:
> > At Sun, 23 Sep 2012 19:08:09 +0200 (CEST),
> > Henning Thielemann wrote:
> >> ==27797== Syscall param ioctl(generic) points to uninitialised byte(s)
> >> ==27797== at 0x5209D27: ioctl (syscall-template.S:82)
> >> ==27797== by 0x4EC9168: snd_seq_hw_query_next_client (seq_hw.c:367)
> >> ==27797== by 0x4ECF3E2: snd_seq_parse_address (seqmid.c:416)
> >> ==27797== by 0x40069D: main (in /home/thielema/programming/haskell/alsa-seq/ctest/parse-address)
> >> ==27797== Address 0x7fefffd24 is on thread 1's stack
> > This is no bug. The uninitialized fields aren't referred in the ioctl
> > at all. valgrind is just too picky, so you can safely ignore it.
> For me valgrind is pretty useless if I have to manually distinguish real
> problems from false alarms in a long list of valgrind messages. Are you
> sure that it is generally ok to pass pointers to uninitialized data to
> ioctl also if in this particular case the pointer is not touched by ioctl?
Only client field is read, and this is the field properly initialized
in alsa-lib code. Others are fields to be filled by the kernel, so it
doesn't matter at all what's left there.
> If yes, then I think valgrind must be somehow teached to ignore this
> particular case.
I have no idea how to teach valgrind, sorry.
More information about the Alsa-devel