[alsa-devel] snd_seq_parse_address accesses uninitialised data

[Takashi Iwai]

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.


Takashi