Wireshark-bugs: [Wireshark-bugs] [Bug 5979] 64-bit Wireshark appears to hit 2-Gbyte memory limit
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Mon, 19 Dec 2011 14:08:40 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5979

--- Comment #5 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2011-12-19 14:08:37 PST ---
(In reply to comment #4)
>     If an application was linked with /LARGEADDRESSAWARE, DUMPBIN /HEADERS will
> display information to that effect.

The 32-bit Wireshark I have installed (1.7.0-SVN-38446--built by the buildbot)
apparently does have this enabled:

C:\Program Files\Wireshark>dumpbin /headers wireshark.exe
Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file wireshark.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
             14C machine (x86)
               5 number of sections
        4E429DB1 time date stamp Wed Aug 10 11:03:13 2011
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
             122 characteristics
                   Executable
                   Application can handle large (>2GB) addresses
                   32 bit word machine
[...]

I don't have a 64-bit Windows to test that on.

> I don't know what happens if a large-address-aware executable runs with a
> non-large-address-aware DLL; if that means that the process isn't treated as
> large-address-aware, and if we're building with a version of the toolchain that
> defaults to /LARGEADDRESSAWARE:NO, we could end up with a
> non-large-address-aware libwiretap or libwsutil and end up with processes
> running Wireshark or TShark being non-large-address-aware.
> 
> However:
> 
>    
> http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/c2d99779-a89b-437e-92ea-18ea64a03c90
> 
> claims that "Only the flag on the .exe matters.", which, if true, makes
> /LARGEADDRESSAWARE irrelevant for DLLs.  It might just be talking about 32-bit
> executables and libraries, though; from some other stuff I found, it looks as
> if /LARGEADDRESSAWARE was originally introduced for *32-bit* code to indicate
> whether the code handles addresses with the high bit set.

That would, if true, be good because I had worried that *all* of Wireshark's
supporting libraries would need to be compiled/linked LARGEADDRESSAWARE (i.e.,
including glib, gtk, etc.).  (Googling for "LARGEADDRESSAWARE DLL" provides
many other indications that that statement is correct.)

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