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?
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
