Wireshark-users: Re: [Wireshark-users] tshark crash with capture ring buffer (-b) and decoding pa
Will Cladek wrote:
The following happens on both tshark 1.0.15 installed from Red Hat
package on CentOS 5 and 1.2.15 from package on CentOS 6.
I am attempting to run tshark on a high-utilization link in a manner
that will print out, using display filters, the user agents of all HTTP
requests. The first problem is that by default, tshark writes all raw
data to temporary capture files in /tmp, so if you leave it running
endlessly, it fills up all of the disk space on the system. To resolve
this, I use the -b option to write to a few files of a set size which
are overwritten.
With just the -b option, I can seemingly run tshark endlessly. For
instance, I ran the following simple capture overnight:
#> tshark -b filesize:100000 -b files:5 -w test.pcap -i eth4
And came back the next morning with over a billion packets having been
processed, but no complaints.
My problem comes when I throw in the -S option to print out the decoded
packets as well for my aforementioned purpose. I run the following
command:
#> tshark -S -b filesize:100000 -b files:5 -w test.pcap -i eth4 > /dev/null
And every time, within a minute, tshark crashes with the message:
tshark: The file "test_00005_20130111092347.pcap" doesn't exist.
(The name of the .pcap file will obviously vary.)
This is follwed by either "Segmentation fault" or something like "***
glibc detected *** tshark: double free or corruption (fasttop):
0x00002ba03da05de0 ***" followed by a printed out Backtrace.
It appears that there is some kind of condition where tshark tries to
delete a ring buffer file that's already been deleted, and this only
occurs when the -S flag is used.
This is an old problem:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1650
Basically tshark isn't keeping up with the rate of traffic that dumpcap
(the capture utility) is writing. dumpcap has gotten N (in your case 5)
files ahead of tshark and removed a file before tshark even got to it.
In other words: dumpcap is writing packets much faster than tshark is
able to read and decode them and then print out the results of that decode.
One suggestion would be to avoid doing a full decode and print ("-S")
but rather limit the decode output significantly ("tshark -T fields
-ehttp.referer"). That might help. You could also mess with process
priorities and the like but I doubt that would buy you much.
