4

I have MFC vc++ app written with VS2010. When I try to allocate double array of size '185000000' using

  1. malloc : it returns NULL
  2. new operator : it throws CMemoryException

But when I write standalone win32 console application in c++ like this:

double *ptr = NULL;
ptr = new double[185000000];

it works fine and ProcessExplorer app shows ~1411MB of memory allcoated.

My MFC app has GUI and lots of libraries added to work with Agilent meter and NI-6255 meter voltage measurement.

Anurag Daware
  • 441
  • 1
  • 5
  • 15
  • 3
    Is your MFC app compiled as 32 or 64 bit? Bear in mind that your process only has 2Gb of address space to play with if it is a 32 bit process. – Rowland Shaw Jul 01 '15 at 11:32
  • 2
    I would guess that the additional DLLs that are loaded in your process' address space cause enough fragmentation that they don't leave 1.5 GB of free contiguous space. If your app is 32-bit, but will actually be run on a 64-bit system, there may be an easy way to solve this problem - see [this answer](http://stackoverflow.com/a/27453226/4326278). – bogdan Jul 01 '15 at 12:00
  • Yes my application is 32 bit running on x64 16GB RAM system.. so should I try building it in 64bit mode? yes there are lot of dll loaded related to MFC and also Agilent meter and NI meter libraries. On side note how do I find out which DLLs are loaded related to my app? – Anurag Daware Jul 01 '15 at 13:38
  • I have two observations: 1. Standalone app is able to allocate ~1411 MB memory without enabling any option. But cannot go beyond 2GB unless I enabled large address space as suggested by bogdan. To go beyond 4GB I need to build standalone app in 64bit mode. 2. For MFC app, I need to enable large address space to get ~1411 MB but it is not able to go beyond 2GB. I shall build it x64 mode. – Anurag Daware Jul 01 '15 at 14:03
  • You can try going 64-bit, but your code and all the libraries involved need to support that configuration. If that's not the case, things can turn ugly. The solution I mentioned in the comment above has the advantage of being very simple (only one linker switch to change), as your app remains 32-bit. Regarding your second question, you can run your program in the Visual C++ debugger and use `Debug -> Windows -> Modules`; there are other tools that you can use as well. – bogdan Jul 01 '15 at 14:13
  • Yeah my requirement has gone have high now as I need to allocate more than 4GB memory and 32 bit app doesn't support that, hence I need to go 64-bit. As you mentioned things are turning out ugly. It is MFC app, if I run GUI, it crashes. If I run this app in command line mode then it runs fine and is able to allocate more than 4GB memory. – Anurag Daware Aug 04 '15 at 08:41

1 Answers1

0

Following link basically solves from problem: https://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx

On x64bit system, 32bit program can go upto 2GB memory. In this limit if additional DLLs are loaded then memory gets fragmented and continuous address space is not available. Hence 1.5GB allocation was failing.

Enabling large address space flag in vs project settings, it can go upto 4GB.

Above that, program needs to be built in 64 bit.

Anurag Daware
  • 441
  • 1
  • 5
  • 15