[alsa-devel] snd_seq_parse_address accesses uninitialised data

[Takashi Iwai]

At Sun, 23 Sep 2012 19:08:09 +0200 (CEST),
Henning Thielemann wrote:
> 
> 
> I think I found a bug. The following small program simply parses an 
> address:
> 
> $ cat ctest/parse-address.c
> #include <alsa/asoundlib.h>
> 
> int main () {
>    snd_seq_t *seq;
> 
>    snd_seq_open(&seq, "default", SND_SEQ_OPEN_DUPLEX, 0);
> 
>    snd_seq_addr_t addr = {128,0};
>    const char *dest_name = "TiMidity";
>    snd_seq_parse_address(seq, &addr, dest_name);
>    printf("found client %s: %d:%d\n", dest_name, addr.client, addr.port);
> 
>    snd_seq_close(seq);
>    return 0;
> }
> 
> $ gcc -Wall -o ctest/parse-address ctest/parse-address.c `pkg-config --libs alsa`
> 
> $ valgrind ctest/parse-address
> ==27797== Memcheck, a memory error detector
> ==27797== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==27797== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==27797== Command: ctest/parse-address
> ==27797==
> ==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.


thanks,

Takashi