0

I'm working on a program used to process pictures of circuits close to a 1:1 micrometer:pixel ratio, so I've got quite a few elements in various vectors that are dynamically allocated (via constructor for CImg). Outside of that, I only have a few Qt widgets allocated.

CImg<unsigned char> image(this->image.width(), this->image.height(), 1, 3, 0);

This is what sets it off.

CImg(const unsigned int size_x, const unsigned int size_y,
    const unsigned int size_z, const unsigned int size_c, const T& value) :
    _is_shared(false) {
    const unsigned long siz = (unsigned long)size_x*size_y*size_z*size_c;
    if (siz) {
        _width = size_x; _height = size_y; _depth = size_z; _spectrum = size_c;
        try { _data = new T[siz]; /*thrown here*/ }
        catch (...) {
            _width = _height = _depth = _spectrum = 0; _data = 0;
            throw CImgInstanceException(_cimg_instance
                "CImg(): Failed to allocate memory (%s) for image (%u,%u,%u,%u).",
                cimg_instance,
                cimg::strbuffersize(sizeof(T)*size_x*size_y*size_z*size_c),
                size_x, size_y, size_z, size_c);
        }
        fill(value);
    }
    else { _width = _height = _depth = _spectrum = 0; _data = 0; }
}

image.width() and image.height() in the constructor call are around 25000 and 900, respectively. That makes siz somewhere in the vicinity of 66 million. So that's about 66MB worth of unsigned chars being allocated.

Googling has given me a bunch of results that suggest memory fragmentation. At its peak usage, the program uses up 2GB. Surely Windows can find a spot for 66MB in the remaining >6GB of memory and this can't be memory fragmentation, right? That said, what else could it be?

I'll add that this only happens after compiling in debug mode, and not after compiling in release mode.

Sarvadi
  • 550
  • 3
  • 13
  • are you running in 32 bit mode? – jdigital Nov 28 '15 at 04:13
  • @jdigital I am indeed. 32 bit program on a 64 bit computer. – Sarvadi Nov 28 '15 at 04:14
  • 1
    fragmentation is more likely to be an issue with the limited address space available to a 32 bit app. – jdigital Nov 28 '15 at 04:15
  • @jdigital That does not address it happening in debug and not in release mode though. – Sarvadi Nov 28 '15 at 04:17
  • http://stackoverflow.com/questions/639540/how-much-memory-can-a-32-bit-process-access-on-a-64-bit-operating-system – jdigital Nov 28 '15 at 04:17
  • regarding debug mode, memory management is handled differently, in order to catch memory allocation problems. sorry i can't give you anything more specific than that. – jdigital Nov 28 '15 at 04:18
  • Remember in debug mode dlls will be larger because of symbols. – drescherjm Nov 28 '15 at 04:19
  • you need to consider the address space, not just the available memory. see the link mentioned above. you certainly don't have access to 6GB of memory -- there's no way you could represent than in a 32 bit address space. – jdigital Nov 28 '15 at 04:21
  • 1
    "At its peak usage, the program uses up 2GB". That's **all** that a 32-bit program has by default in Windows. The other 2GB is used for loading system DLLs and such. You can configure things to get 3GB for the program's own purposes, but I would just build this as a 64-bit program. Assuming that's supported by Qt. If it's not supported then I would separate the GUI and functionality. Which is a good idea anyway. – Cheers and hth. - Alf Nov 28 '15 at 04:21
  • @jdigital That appears to have fixed it. Thanks. – Sarvadi Nov 28 '15 at 04:25

1 Answers1

2

Fixed. Needed /LARGEADDRESSAWARE to combat 32 bit memory limitations.

Thank you @jdigital.

Sarvadi
  • 550
  • 3
  • 13