Wireshark-users: Re: [Wireshark-users] assertion when using tshark/wireshark on large captures
On Feb 16, 2011, at 2:31 PM, Bahr, Brad (Adecco Engineering & Technical) wrote:
> 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”.
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.)
