Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 5699] New: assertion when using tshark/wireshark on large captures

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5699

           Summary: assertion when using tshark/wireshark on large
                    captures
           Product: Wireshark
           Version: 1.4.3
          Platform: x86-64
        OS/Version: Windows 7
            Status: NEW
          Severity: Major
          Priority: Low
         Component: TShark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: brad@xxxxxxxxxxxx


Build Information:
TShark 1.4.3 (SVN Rev 35482 from /trunk-1.4)

Copyright 1998-2011 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 (64-bit) with GLib 2.22.4, with WinPcap (version unknown), with libz
1.2.3, without POSIX capabilities, without libpcre, without SMI, with c-ares
1.7.1, with Lua 5.1, without Python, with GnuTLS 2.8.5, with Gcrypt 1.4.5,
without Kerberos, with GeoIP.

Running on 64-bit Windows 7, build 7600, with WinPcap version 4.1.2 (packet.dll
version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008).

Built using Microsoft Visual C++ 9.0 build 30729
--
I submitted the following on the wireshark-users mailing list.  Steve Fisher
recommended that I file this as a bug so that it might be investigated further.


"I am running the 64bit version of Wireshark/tshark (v1.4.3 rev35482 – compiled
download) on a 64bit Windows 7 box.  When I am applying read filters to large
captures (1.5GB+) with tshark, I get this assertion:

ERROR:emem.c:652:???: assertion failed: (ret != 0 || versinfo.dwPlatformId ==
VER_PLATFORM_WIN32_WINDOWS)

Also in stderr are numerous warnings about dissector bugs with the SMB2 and VNC
protocols.  I’m not sure if these are related but thought they would be worth
mentioning.  From a cursory glance at the source heading of emem.c, I gather
that this file provides memory management / garbage cleanup functions.  I’m
definitely a novice when it comes to C/C++, so I don’t have a clue as to what
would be causing g_assert to be getting a false from “ret != 0 ||
versinfo.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS”.  

If I try to open this same capture file with Wireshark, it also dies a terrible
death before the capture is loaded.  Both tshark and Wireshark seem to be
croaking when they have consumed about 2GB of memory, which makes me wonder if
its related to some 32bit snafu.  My box has dual quad xeons and 12GB of ram,
so hardware is likely not a concern."





Guy Harris's response:

It means that an attempt to make a "guard page" completely inaccessible, failed
when running on 64-bit Windows.  "Guard pages" are put between allocations to
catch code that overflows allocated memory.

Why that happened is another matter; we may need to check for its failure with
something more than an assert, so that we can log the reason why
VirtualProtect() failed and try to debug it.  Or is intptr_t 32-bit in 64-bit
mode, or something silly such as that, so the calculation of the address of the
beginning of the guard page fails if the pointer returned by VirtualAlloc()
doesn't fit in 32 bits?  (There's also the question of "negative pointers" on
x86-64; I don't know whether the "negative space" is user-space or kernel-space
on Win64, so I don't know whether you'd get a "negative pointer" from an
allocation.) 


Steve Fisher's Response:

This is interesting.  SVN revision 18178 introduced this to attempt to recover
after the VirtualProtect() funcion call fails I think:

  http://anonsvn.wireshark.org/viewvc?view=rev&revision=18178

Which was to fix bug #915 on Windows 98! 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=915

You should probably open a bug report at https://bugs.wireshark.org and include
the details from this e-mail.  Depending on the complexity of the information
Wireshark has to reassemble and store about the packets, you could still be
running out of RAM with that large capture file, but this is an unusual place
for it to fail.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.