[bugzilla-daemon@xxxxxxxxxxxxx]

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.