Memory allocation problems
Al Greynolds
array. On one of my Windows XP Pro (SP3) systems the allocation
suceeds, on another it fails. Task manager shows about 2.8GB physical
memory (>5GB virtual) available on both before launching the EXE.
I suspect that the address space is fragmented on the one system so
that a contiguous 1.5GB allocation is not possible. Are there any
utilities available that can display a memory allocation map to verify
this? Are there any other possible causes I should be looking into?
Al Greynolds
www.ruda.com
Steve Lionel
> I have an IVF generated EXE that tries to allocate a single 1.5GB
> array. On one of my Windows XP Pro (SP3) systems the allocation
> suceeds, on another it fails. Task manager shows about 2.8GB physical
> memory (>5GB virtual) available on both before launching the EXE.
I don't know what you're looking at for the "virtual" value. A single
process in 32-bit Windows is limited to 2GB virtual address space. More
physical RAM does not increase this. Any DLLs loaded take up some of
this space and on some systems there may be more "hook" DLLs loaded than
on others. You can see these in the VS debugger with address ranges by
starting the program under the debugger and selecting Debug > Windows >
Modules.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
Al Greynolds
> I don't know what you're looking at for the "virtual" value. A single
> process in 32-bit Windows is limited to 2GB virtual address space. More
> physical RAM does not increase this.
Opps! I don't know why I wrote "virtual". This number is the "commit
charge limit".
> Any DLLs loaded take up some of
> this space and on some systems there may be more "hook" DLLs loaded than
> on others. You can see these in the VS debugger with address ranges by
> starting the program under the debugger and selecting Debug > Windows >
> Modules.
Could this also be accomplished by running the loadtest command line
utility on the EXE? With it I get the following on both systems:
C:\ivf\bin>loadtest geloe4.exe
Image load at 400000 of: geloe4.exe
DLL load at 7c900000 of: ntdll.dll
DLL load at 7c800000 of: C:\WINDOWS\system32\kernel32.dll
DLL load at 76c90000 of: C:\WINDOWS\system32\imagehlp.dll
DLL load at 77c10000 of: C:\WINDOWS\system32\msvcrt.dll
Al
Al Greynolds
Actually both machines have the /3GB switch in their BOOT.INI and the
EXE is built with the /largeaddressaware linker switch.
Al
Steve Lionel
> On Jun 5, 1:43 pm, Steve Lionel <steve.lio...@intel.invalid> wrote:
>> I don't know what you're looking at for the "virtual" value. A single
>> process in 32-bit Windows is limited to 2GB virtual address space. More
>> physical RAM does not increase this.
>
> Opps! I don't know why I wrote "virtual". This number is the "commit
> charge limit".
Ok - that is a system-wide value and does not reflect resources
available to a given process.
> Could this also be accomplished by running the loadtest command line
> utility on the EXE? With it I get the following on both systems:
>
> C:\ivf\bin>loadtest geloe4.exe
>
> Image load at 400000 of: geloe4.exe
> DLL load at 7c900000 of: ntdll.dll
> DLL load at 7c800000 of: C:\WINDOWS\system32\kernel32.dll
> DLL load at 76c90000 of: C:\WINDOWS\system32\imagehlp.dll
> DLL load at 77c10000 of: C:\WINDOWS\system32\msvcrt.dll
No - all that tells you is the DLLs explicitly pulled in by this exe -
it doesn't tell you what "hook" DLLs automatically load.
As for your use of /3GB, mentioned in another post, that does increase
the process space to 3GB but that space is not contiguous.
Al Greynolds
Thanks for the info. I don't use the VisualStudio IDE but I was able
to track down the "hook" DLL's using Mark Russinovich's free
ProcessExplorer (http://technet.microsoft.com/en-us/sysinternals/
bb896653.aspx). I inserted a PAUSE into my Fortran source just before
the ALLOCATE of interest. The older system that couldn't do the
allocation has about twice the DLL's loaded at that point. Now all I
have to do is figure out what additional installed software is
responsible.
Thanks again,
Al