No my patch doesn't fix it.
On Dec 1, 2003, at 1:50 PM, didier wrote:
3 things - there's a bug in reassembling code with lost frame. - an unfinished fix for reassemble.c
Does your patch address both of those? Or are they the same problem?
The bug only shows reassemble code slowness with big segments. Patch short cuts a foreach search.
It's unfinished because there're other functions where it could be used too.
Bug I've seen :
I have an AFP capture with FPwrite commands, segments are between 20kBytes to 65kBytes.
There're lost frames/dup and file has been truncated in a frame.
The last unreassembled segment is in frame 25500 and there's a *lot* of frames with
'reassembled PDU in frame 25500 '
for a grand total of 0x293740 bytes (2 701 120 decimal!)
when it should be only the last 65kB.
sure.
- with huge capture, by huge I mean capture where ethereal memory usage is > physical memory, I've seen system load > 40%
using mallopt (M_MMAP_MAX, 0); mallopt (M_TOP_PAD, 10*1024*1024); mallopt (M_TRIM_THRESHOLD, 20*1024*1024); help a lot, system < 10%
...on platforms that have "mallopt()" and those options for it.
Didier
