[bugzilla-daemon@xxxxxxxxxxxxx]

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

--- Comment #4 from Guy Harris <guy@xxxxxxxxxxxx> 2011-12-18 12:56:36 PST ---
I said

    (There's a 2GB file size limit in 1.4.5 because, in all Ethereal/Wireshark
releases prior to 1.5, and in the 1.5 (trunk) until recently, the calls used to
seek into the capture file used a 32-bit file offset, even on most 64-bit
platforms, including Windows.)

but that's a file size limit, based on API limitations, not an address space
size limit.

As we don't know the reason why we're seeing a crash that looks like an address
space size limit on Win64, we haven't fixed it.

However, Teh Google for

    address space size limit win64

found

   
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx

which has a section "Memory and Address Space Limits" that says, for 64-bit
applications on 64-bit Windows:

    With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default):

        x64:  8 TB

        Intel Itanium-based systems:  7 TB

    2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared

It says earlier

    IMAGE_FILE_LARGE_ADDRESS_AWARE is set or cleared by using the
/LARGEADDRESSAWARE linker option.

We're passing /LARGEADDRESSAWARE in Makefile.nmake and epan/Makefile.nmake (but
not in other nmake files).

The VS 2005 documentation says:

    The /LARGEADDRESSAWARE option tells the linker that the application can
handle addresses larger than 2 gigabytes. By default, /LARGEADDRESSAWARE:NO is
enabled if /LARGEADDRESSAWARE is not otherwise specified on the linker line.

    If an application was linked with /LARGEADDRESSAWARE, DUMPBIN /HEADERS will
display information to that effect.

That seems to imply that, for VS 2005, /LARGEADDRESSAWARE is *NOT* the default!

The VS 2008 documentation says the same.

The VS 2003 documentation just says

    The /LARGEADDRESSWARE option tells the linker that the application can
handle addresses larger than 2 gigabytes.

(along with the bit about DUMPBIN, which I'll omit from other quotes); it says
nothing about the default.

The VS 2010 documentation says

    The /LARGEADDRESSAWARE option tells the linker that the application can
handle addresses larger than 2 gigabytes. In the 64-bit compilers, this option
is enabled by default. In the 32-bit compilers, /LARGEADDRESSAWARE:NO is
enabled if /LARGEADDRESSAWARE is not otherwise specified on the linker line.

so I guess "/LARGEADDRESSAWARE is the default" doesn't apply until VS 2010.

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.

-- 
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.