[Snort-devel] Re: Frag memory leak data

Dragos Ruiu dr at ...40...
Wed Nov 8 17:50:58 EST 2000


Suggestion.... we keep tcpdump headers around.... for timestamps..
but they also have capture length.

I already track the memory  use to see when to kick in garbage collection
which pretty much seems to not kick in. That's the ifdef at the beginning
for high memory use (FASTSWEEPLIM)  (But it is assuming the memory is 
freed by virtue of the os keeping track of memory regions. Silly me. How
presumptuous. ;-) That's derived from old memory of unix mem alloc code, 
it would be nice to understand this from someone with a better understanding of
POSIX, and then practical reality :-).

my question is how to force free to free the memory region to a contolled length
from a variable?  "man -k memory" time... or maybe playing with ugh...
MALLOC_OPTIONS... woop woop danger will robinson. :-0

Let's sync versions because I documented and put diagnostic printouts
next to all the alloc's last night.  I was using your CVS base.

Back in a couple of hours to work on it.

cheers,
--dr

On Wed, 08 Nov 2000, Martin Roesch wrote:
> I've been playing around with the defragger's giant gaping memory leak, and
> I've added some debug code to aid in the analysis.  As you can see, there
> seems to be a problem in freeing up memory.  I think it'd be helpful to label
> the various free's and mallocs in the defrag code for printout when they're
> accessed (next to the counters I've added) to see where the disparities
> happen.  
> 
> As far as I can see, the amount of memory freed at the following places is
> ambiguous (based on the code I just checked into CVS):
> 
> Line 581:
> 
> if(np)
> {
>     free(np);
> }
> 
> In this case, np is a u_char* pointing to a struct pcap_pkthdr that has been
> filled with the entire packet's contents and cast back to the char pointer. 
> I'm worried that this is only freeing 4 bytes.
> 
> Line 736:
> 
> free(freetemp->pkth);  /* free packet copy */
> free(freetemp);
> 
> Once again I'm worried how much data is actually being freed here, it was
> difficult for me to calculate how much memory was being used in my debug
> counter code.  There's an identical set of calls at line 761 as well.
> 
> Has anyone got a good technique for seeing precisely how much memory is being
> allocated and freed by specific system calls?  Are there any syscalls we can
> make?  Could ElectricFence help us out here?  (Probably not, it mostly looks
> for out of bounds reads/writes...)
> 
> Here's a sample run (the spp_defrag.c module was compiled with -DDEBUG):
> 
> -*> Snort! <*-
> Version 1.7-beta3
> By Martin Roesch (roesch at ...16..., www.snort.org)
> fragments =>
>     mem used: 0
>     mem freed: 0
> fragments =>
>     mem used: 0
>     mem freed: 0
> fragments =>
>     mem used: 0
>     mem freed: 0
> fragments =>
>     mem used: 0
>     mem freed: 0
> fragments =>
>     mem used: 0
>     mem freed: 0
> fragments =>
>     mem used: 1104
>     mem freed: 0
> psize calculated to be 20 bytes (last payload: 4)(last offset: 16)
> Overhead = 18, struct size = 16
> sip1 = 0x401010A, sip2 = 0x401010A
> dip1 = 0x101010A, dip2 = 0x101010A
> id1 = 58107, id2 = 58107
> proto1 = 6, proto2 = 6
> fragrank = 2, froot = 0x841d100, fragaddrmatch = 1
> sip1 = 0x401010A, sip2 = 0x401010A
> dip1 = 0x101010A, dip2 = 0x101010A
> id1 = 58107, id2 = 58107
> proto1 = 6, proto2 = 6
> Writing 4 bytes from 0x8413434 at 0x84134c4
> reassembly writecount: 4
> sip1 = 0x401010A, sip2 = 0x401010A
> dip1 = 0x101010A, dip2 = 0x101010A
> id1 = 58107, id2 = 58107
> proto1 = 6, proto2 = 6
> Writing 16 bytes from 0x84133b4 at 0x84134b4
> reassembly writecount: 20
> Fragmented packet rebuilt, processing...
> BPF header (18 bytes):
> E7 D2 09 3A 0A B8 03 00 48 00 00 00 48 00 00 00  ...:....H...H...
> 12 00                                            ..
> 
> Packet dump (72 bytes):
> 00 10 4B 0D E4 8C 00 A0 CC 3A 93 A3 08 00 45 00  ..K......:....E.
> 00 14 FB E2 00 00 40 06 68 F5 0A 01 01 04 0A 01  ...... at ...113...
> 01 01 8B D2 00 15 29 16 28 1A 00 00 00 00 50 02  ......).(.....P.
> 08 00 B4 C4 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 00 00 00 00 00 00 00 00                          ........
> 
> fragments =>
>     mem used: 3296
>     mem freed: 64
> fragments =>
>     mem used: 3296
>     mem freed: 1152
> fragments =>
>     mem used: 3296
>     mem freed: 1152
> ^C
> Exiting...
> 
> 
> ===============================================================================
> Snort received 8 packets and dropped 0(0.000%) packets
> 
> Breakdown by protocol:
>     TCP: 5          (62.500%)
>     UDP: 0          (0.000%)
>    ICMP: 2          (25.000%)
>   FRAGS: 2          (25.000%)
> REBUILT: 1          (12.500%)
>     ARP: 0          (0.000%)
>    IPv6: 0          (0.000%)
>     IPX: 0          (0.000%)
>   OTHER: 0          (0.000%)
> ===============================================================================
>  ALERTS: 1         
>  LOGGED: 0         
>  PASSED: 0         
> ===============================================================================
> 
> -- 
> Martin Roesch
> roesch at ...48...
> http://www.snort.org
-- 
Dragos Ruiu <dr at ...9...>   dursec.com ltd. / kyx.net - we're from the future 
gpg/pgp key on file at wwwkeys.pgp.net



More information about the Snort-devel mailing list