Comment # 10
on bug 8022
from Cristian Constantin
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #5)
> > > The reconstructed capture file is 1.6 GB in size and contains some 2 million
> > > packets. I've split it up into 100,000-packet chunks and have not been able
> > > to reproduce the issue, but I don't have enough RAM available to open the
> > > entire file at once.
> >
> > The radix tree (or whatever that data structure is called)
>
> It is a radix tree, although it's implemented rather oddly (with the
> hard-coded level counts everywhere). Realistically we're never going to get
> 2^40 packets worth of frame data, but there is a small part of me that wants
> to rewrite it to cleanly support an arbitrary number of levels.
>
> > for the frame
> > data structures needs to get sufficiently deep for the problem to show up,
> > so a smaller file might not do the job. 0-1024 frames -> root node + leaf
> > nodes, and 1025-1048576 frames -> root node + 1 level of intermediate nodes
> > + leaf nodes, so you need > 1048576 nodes to get to 2 levels of intermediate
> > nodes.
>
> This makes sense. Sounds like I'm going to need to invest in more RAM to
> reproduce - I've been looking for an excuse ;)
cristian: I don't want to be mean here, but that capture is around 30 seconds
of
flood with sctp traffic over an ethernet gigabit. so, nothing unusual for the
year 2012, right?
I also saw that only large capture files (i.e. over 1 Gigabyte) cause this type
of crash.
otoh, ram is getting so cheap nowadays... :-)
thanks!
You are receiving this mail because:
- You are watching all bug changes.