I'm currently working on a legacy app (win32, Visual C++ 2005) that allocates memory using LocalAlloc (in a supplied library I can't change). The app keeps very large state in fixed memory (created at the start with multiple calls to LocalAlloc( LPTR, size)). I notice that in release mode I run out of memory at about 1.8gb but in debug it happily goes on to over 3.8gb. I'm running XP64 with the /3gb switch. I need to increase the memory used in the app and I'm hitting the memory limit in release (debug works ok). Any ideas?
+1
A:
Sounds like your Release build is also compiled as x86. If not, than there must be something in your code which treats pointer as signed 32-bit integers and this code is only active in Release.
How does the running out of memory manifests itself?
Also, there is no reason to use /3gb flag for XP64 when running 64-bit applications: it doesn't change anything in this scenario
Rom
2009-06-04 11:30:47
Not a 64bit app.
Tim Ring
2009-06-04 11:38:25
Ok, I assumed that it's a 64-bit app since you get 3.8Gb. Yes, you're right, this can be done from a 32-bit under 64-bit OS. So how does the running out of memory manifests itself? I'd suggest looking there first
Rom
2009-06-04 11:46:10
Running out of memory manifests itself by a call to LocalAlloc returning NULL.... :-)
Tim Ring
2009-06-04 12:23:43
A:
Why do you need to allocate such memory size ?
Do you have memory leaks ?
I have some real solutions for memory leaks, just let me know.
pixel3cs
2009-06-04 11:34:13
a) I just do.b) I don't have any memory leaks. As I said all memory is allocated at start.
Tim Ring
2009-06-04 11:38:28
You have not contributed anything worthwhile to this discussion. His requirements may be that he needs a large about of RAM. It does not mean it is a memory leak.
dreamlax
2009-06-04 11:40:48
A:
One suggestion: have a look at the base addresses of the DLLs that get loaded into the process space in release and debug mode, and see if there is much difference. It's possible that, in the release case, there are DLLs loaded at addresses so that, while there's enough free space in total to support a LocalAlloc() call, there isn't enough continuous address space to satisfy it. (For a contrived example, suppose that there was a DLL loaded at 0x40000000 (1Gb), another at 0x80000000 (2Gb), and another at 0xC0000000 (3Gb). Even if these DLLs were really small, the process couldn't allocate more than 1Gb at a time, as there's no continuous block of address space left free that's big enough).
You could also get a variation on this problem if the memory allocations happened in a different order in debug and release, too.
DavidK
2009-06-04 14:53:13
+3
A:
You probably have the Debug configuration linking with /LARGEADDRESSAWARE and the Release configuration linking with /LARGEADDRESSAWARE:NO (or missing altogether).
Check Linker->System->Enable Large Addresses in the project's configuration properties.
comshak
2009-06-04 15:07:15