Guy, thanks so much for putting me straight! It looks like the coding examples I'd been using to put together this quick-n-dirty hack were flawed. I didn't have sufficient time to focus on it but I was sure I was confused on the pointer-to-pointers bit - for some reason when I'm tired I always get that wrong!
The new output of valgrind (for 32-bit) shows uninitialised bytes during a call to setsockopt() inside pcap_setfilter(), and a 'reachable' block due to an malloc, but the leaks have gone away :) I doubt we'll be able to test the revised code in the diagnosis app on the 64-bit servers until Monday now, but at least I can crack on with some confidence now. TJ. ==26808== Syscall param socketcall.setsockopt(optval) points to uninitialised byte(s) ==26808== at 0x40007F2: (within /lib/ld-2.5.so) ==26808== by 0x804BC98: pcap_setfilter (in /home/all/Projects/packeteer/test-libpcap) ==26808== by 0x804980C: main (test-libpcap.c:53) ==26808== Address 0xBEA34532 is on thread 1's stack pcap_setfilter() done Finished ==26808== ==26808== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 11 from 1) ==26808== malloc/free: in use at exit: 4 bytes in 1 blocks. ==26808== malloc/free: 116 allocs, 115 frees, 21,420 bytes allocated. ==26808== For counts of detected errors, rerun with: -v ==26808== searching for pointers to 1 not-freed blocks. ==26808== checked 59,744 bytes. ==26808== ==26808== LEAK SUMMARY: ==26808== definitely lost: 0 bytes in 0 blocks. ==26808== possibly lost: 0 bytes in 0 blocks. ==26808== still reachable: 4 bytes in 1 blocks. ==26808== suppressed: 0 bytes in 0 blocks. ==26808== Reachable blocks (those to which a pointer was found) are not shown. ==26808== To see them, rerun with: --show-reachable=yes On Fri, 2007-08-10 at 22:07 -0700, Guy Harris wrote: > > In your program, replace > > pcap_if_t *this_dev; > pcap_if_t **alldevsp = &this_dev; > > with > > pcap_if_t *alldevs, *this_dev; ... - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
