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 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 wrote: > 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
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".
> 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 Greynolds wrote: > 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.
--
Steve Lionel Developer Products Division Intel Corporation Nashua, NH
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.
