Note that there are some explanatory texts on larger screens.

plurals
  1. POnew operator (as well as malloc) fails to allocate ~ 450 MB of memory
    text
    copied!<p>I'm working on a program which stores an array of roughly 220 mln short values in memory. This block of data is allocated like this:</p> <pre><code>short * arrayName = new short[SIZE_OF_ARRAY]; </code></pre> <p>And then the contents of a file are read into memory. After a big massive update of the overall architecture of the program by another person in the team, this exact line started to crash the program. The message is this:</p> <pre><code>Microsoft Visual C++ Runtime Library Runtime Error! abnormal program termination </code></pre> <p>It happens immediately at this call of memory allocation (no further lines, such as a check to see if the pointer is NULL, are executed). Even after a few days, it's unclear to us what change in the other code exactly caused this line to start behaving this way (actually nothing which is even remotely linked to this array was changed).</p> <p>On Linux (Ubuntu, to be exact), everything is working fine; this problem exists only on Windows machines. On 64-bit Windows OSes, this workaround helps (in .pro file):</p> <pre><code>QMAKE_LFLAGS_WINDOWS += /LARGEADDRESSAWARE </code></pre> <p>On 32-bit, it doesn't help.</p> <p>Replacing the line with malloc the following way has let me check if the pointer is NULL after it (which it is) and to get the error code out of errno, which is 12 (ENOMEM) = "Not enough memory".</p> <pre><code>short * arrayName = (short *)malloc(SIZE_OF_ARRAY * sizeof(short)); </code></pre> <p><a href="https://stackoverflow.com/questions/8370264/malloc-returns-null-and-sets-errno-to-enomem-but-there-is-plenty-of-heap-space">This StackOverflow question</a> seems to be about the same problem; its similarity is even up to the point that allocating a smaller amount of memory works (but 450 MB does not). The answers there suggested high memory fragmentation and that new / malloc cannot allocate a continuous memory region, but in my case, the problem persists even freshly after a reboot when only ~ 600 MB out of 2 physical GBs (and 4 virtual GBs) have been used, so it is somewhat ruled out (additionally, like I mentioned, the exact same line of code had worked before).</p> <p>My main suspicion is that it has something to do with heap size (although I'm not sure if new and malloc both allocate memory to heap; and also I haven't yet found a way to change heap size in Qt). Am I missing something here?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload