Re: libpcap: Memory-loeaks SIGSEGV

[TJ <tj () tjworld net>]

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.