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