|
From: Henning T. <le...@he...> - 2012-09-24 15:07:06
|
I got a valgrind error message for the following small ALSA program:
$ 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 /tmp/alsa-seq/ctest/parse-address)
==27797== Address 0x7fefffd24 is on thread 1's stack
==27797==
found client TiMidity: 129:0
==27797==
==27797== HEAP SUMMARY:
==27797== in use at exit: 75,317 bytes in 1,409 blocks
==27797== total heap usage: 2,054 allocs, 645 frees, 278,456 bytes allocated
==27797==
==27797== LEAK SUMMARY:
==27797== definitely lost: 0 bytes in 0 blocks
==27797== indirectly lost: 0 bytes in 0 blocks
==27797== possibly lost: 42,852 bytes in 1,310 blocks
==27797== still reachable: 32,465 bytes in 99 blocks
==27797== suppressed: 0 bytes in 0 blocks
==27797== Rerun with --leak-check=full to see details of leaked memory
==27797==
==27797== For counts of detected and suppressed errors, rerun with: -v
==27797== Use --track-origins=yes to see where uninitialised values come from
==27797== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
$ pkg-config --modversion alsa
1.0.25
The ALSA developers say that this is no problem since ioctl would not
touch the pointer. Is it correct to use ioctl this way? If yes, can
valgrind be instructed to ignore this case?
|
|
From: John R. <jr...@bi...> - 2012-09-24 16:25:58
|
> The ALSA developers say that this is no problem since ioctl would not > touch the pointer. Is it correct to use ioctl this way? ioctl() related to "sound" is notoriously murky: poorly documented and a cesspool of partial implementation (many corner cases, unfinished code, tends to work only for the well-worn ruts of common usage.) Notice the "ioctl(generic)": memcheck doesn't even differentiate _which_ ioctl is being used, so memcheck cannot know that this specific case is supposed not to touch a memory region. (The ALSA developers could ameliorate the situation quite easily by passing a pointer to known-initialized memory.) > If yes, can valgrind be instructed to ignore this case? See: $ valgrind --help | grep suppress -- |