dect
/
libpcap
Archived
13
0
Fork 0
Code Releases Activity

So far, two people have submitted patches to "fix" the "memory leak" in 

icode_to_fcode() by having it free the bpf_insn array before returning a
pointer to it.  Add a comment to icode_to_fcode() explaining why this is
not a leak in icode_to_fcode(), it's a leak in their program, and
indicating how to fix the leak.
This commit is contained in:
guy 2007-07-15 19:53:54 +00:00
parent 56634b504f
commit 1e678955ad
1 changed files with 15 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
optimize.c
View File

@ -22,7 +22,7 @@
*/
#ifndef lint
static const char rcsid[] _U_ =
"@(#) $Header: /tcpdump/master/libpcap/optimize.c,v 1.87 2007-06-11 10:04:25 guy Exp $ (LBL)";
"@(#) $Header: /tcpdump/master/libpcap/optimize.c,v 1.88 2007-07-15 19:53:54 guy Exp $ (LBL)";
#endif
#ifdef HAVE_CONFIG_H
@ -2227,6 +2227,20 @@ filled:
/*
* Convert flowgraph intermediate representation to the
* BPF array representation. Set *lenp to the number of instructions.
*
* This routine does *NOT* leak the memory pointed to by fp. It *must
* not* do free(fp) before returning fp; doing so would make no sense,
* as the BPF array pointed to by the return value of icode_to_fcode()
* must be valid - it's being returned for use in a bpf_program structure.
*
* If it appears that icode_to_fcode() is leaking, the problem is that
* the program using pcap_compile() is failing to free the memory in
* the BPF program when it's done - the leak is in the program, not in
* the routine that happens to be allocating the memory. (By analogy, if
* a program calls fopen() without ever calling fclose() on the FILE *,
* it will leak the FILE structure; the leak is not in fopen(), it's in
* the program.) Change the program to use pcap_freecode() when it's
* done with the filter program. See the pcap man page.
*/
struct bpf_insn *
icode_to_fcode(root, lenp)