https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3172
Summary: tshark fails to properly close capture files when
opening new ones
Product: Wireshark
Version: 1.0.5
Platform: PC
OS/Version: Red Hat
Status: NEW
Severity: Major
Priority: High
Component: TShark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: hunter@xxxxxxxxxx
Seth Hunter <hunter@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #2622| |review_for_checkin?
Flag| |
Created an attachment (id=2622)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2622)
Patch to resolve issue reported
Build Information:
TShark 1.0.5 (SVN Rev 26954)
Copyright 1998-2008 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GLib 2.14.6, with libpcap 0.9.7, with libz 1.2.3, without POSIX
capabilities, without libpcre, without SMI, without ADNS, without Lua, without
GnuTLS, without Gcrypt, with MIT Kerberos.
NOTE: this build doesn't support the "matches" operator for Wireshark filter
syntax.
Running on Linux 2.6.26.6-49.fc8, with libpcap version 0.9.7.
Built using gcc 4.1.2 20070925 (Red Hat 4.1.2-33).
--
When running in "multiple files mode" (-b command line option), tshark is
supposed to rotate its capture output among a collection of files in a
ringbuffer-like manner. A good reason for a user to do this is to prevent a
long-running capture from filling up a disk.
It was noticed while testing with a relatively small tmpfs partition that
tshark was unlinking old/full capture files but was not closing the
corresponding file descriptor. The result was that the data on disk was not
freed up until the process finished, causing the disk to fill up and tshark to
ultimately shutdown prematurely. This clearly negated the aforementioned
reason why a user might want to use the "multiple files mode." Example 'lsof'
output illustrating this behavior in the 'tshark' process (the corresponding
'dumpcap' process behaves properly):
tshark 10659 root 5r REG 0,22 262219 940463
/tmp/ramdisk/wlan_00001_20090104112611.cap (deleted)
tshark 10659 root 6r REG 0,22 262514 940469
/tmp/ramdisk/wlan_00002_20090104112706.cap (deleted)
tshark 10659 root 7r REG 0,22 262179 940470
/tmp/ramdisk/wlan_00003_20090104112729.cap (deleted)
tshark 10659 root 8r REG 0,22 262208 940473
/tmp/ramdisk/wlan_00004_20090104112734.cap (deleted)
tshark 10659 root 9r REG 0,22 262192 940492
/tmp/ramdisk/wlan_00005_20090104112831.cap (deleted)
tshark 10659 root 10r REG 0,22 262179 940594
/tmp/ramdisk/wlan_00006_20090104112932.cap (deleted)
tshark 10659 root 11r REG 0,22 262169 940618
/tmp/ramdisk/wlan_00007_20090104113032.cap (deleted)
tshark 10659 root 12r REG 0,22 262220 940676
/tmp/ramdisk/wlan_00008_20090104113135.cap (deleted)
tshark 10659 root 13r REG 0,22 263033 940680
/tmp/ramdisk/wlan_00009_20090104113228.cap (deleted)
tshark 10659 root 14r REG 0,22 262384 940683
/tmp/ramdisk/wlan_00010_20090104113236.cap (deleted)
tshark 10659 root 15r REG 0,22 262275 940684
/tmp/ramdisk/wlan_00011_20090104113239.cap
tshark 10659 root 16r REG 0,22 262149 940685
/tmp/ramdisk/wlan_00012_20090104113244.cap
tshark 10659 root 17r REG 0,22 84113 940689
/tmp/ramdisk/wlan_00013_20090104113328.cap
The problem appears to me to be that the cf_open() function in tshark.c does
not properly set the 'state' variable of the 'capture_file' structure, causing
the capture_input_new_file() function to not attempt to wtap_close() the file
descriptor. The attached patch resolves this problem for me.
As an aside, why does tshark.c redefine its own cf_open(), when it appears to
be better-defined in file.c?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
