Virtual Memory Exhausted

[moulik]

My goal is to input a DICOM image, replace the pixel data with a new set of data and write it to a separate DICOM image.
The code is as follows (segbuffer is an array 512x512 of shorts, opt_ifname is a valid char string).


DcmFileFormat ofileformat;
OFCondition ostatus = ofileformat.loadFile(opt_ifname);
DcmDataset *dataset = ofileformat.getDataset();

ostatus = dataset->putAndInsertSint16Array(DCM_PixelData, segbuffer, 512*512, OFTrue);
if (ostatus.bad()){cerr << "Error: cannot insert new data array (" << ostatus.text() << ")" << endl;}


ostatus = ofileformat.saveFile(opt_ofname);
if(ostatus.bad()){cerr << "Error: cannot write DICOM file (" << ostatus.text() << ")" << endl;}



No matter what I do, I get a Virtual Memory Exhausted Error (windows and linux)(single and multi threaded).
Any thoughts?

[Michael Onken]

Hi,

just took a quick look, but maybe try to save to another filename?
Or, call loadAllDataIntoMemory() on the fileformat just after loadFile(). If that does not help I'll take a closer look

Best regards,
Michael

[moulik]

Michael,
Thanks for your quick response. I actually did try your suggestion earlier and it did not change the error.
I guess my code snipet is incomplete, but I am reading from "file name 1" and writing to "file name 2".

Thanks,
Supratik

[Silvermaul]

Sorry for resurrecting a dead thread but I just got the same problem. I am rescaling some images and when I try to save the new file it returns :

Dcmtk function : putAndInsertUint16Array
Returned : Virtual Memory exhausted

My computer is doesn't have so many resource (2GB RAM). Perhaps this is the problem?? Or is this a known issue? I can downscale images with the same tactic but upscaling seems to casue the issue.

[moulik]

I don't think it is related to your system memory because I am working with 8GB and 512x512 images. Did you do a custom build of the library? Specifically, did you mess with the multithreading options?

[Michael Onken]

Hi,

at least with 8GB of course you should not run into those problems with such small images. Also, with 2GB it is uncommon unless you insert values around 1 Gigabyte or so.

@Silvermaul: Which element do you try to fill with putAndInsertUint16Array, also the Pixel Data element?

And/Or are you both able to debug in which line the allocating of memory actually fails?

Best regards,
Michael

[insight]

At least in putAndInsertSint16Array "EC_MemoryExhausted" is also returned on illegal VRs - the EC_IllegalCall gets replaced if elem == NULL
This seems to be different in putAndInsertUint16Array, but maybe this is a recent addition to the code?

At least this was the solution to the same problem I had while using putAndInsertSint16Array - the VR was OW and not xs.
hth
Christian

[Jörg Riesmeier]

At least in putAndInsertSint16Array "EC_MemoryExhausted" is also returned on illegal VRs - the EC_IllegalCall gets replaced if elem == NULL
This seems to be different in putAndInsertUint16Array, but maybe this is a recent addition to the code?

You are right, there was a bug that has already been fixed some time ago.

[insight]

It is not fixed in putAndInsertSint16Array

[Jörg Riesmeier]

Here's the current implementation:

Code: Select all

OFCondition DcmItem::putAndInsertSint16Array(const DcmTag& tag,
                                             const Sint16 *value,
                                             const unsigned long count,
                                             const OFBool replaceOld)
{
    OFCondition status = EC_Normal;
    DcmElement *elem = NULL;
    /* create new element */
    switch(tag.getEVR())
    {
        case EVR_SS:
            elem = new DcmSignedShort(tag);
            break;
        case EVR_lt:
        case EVR_xs:
            /* special handling */
            elem = new DcmSignedShort(DcmTag(tag, EVR_SS));
            break;
        default:
            status = EC_IllegalCall;
            break;
    }
    if (elem != NULL)
    {
        /* put value */
        status = elem->putSint16Array(value, count);
        /* insert into dataset/item */
        if (status.good())
            status = insert(elem, replaceOld);
        /* could not be inserted, therefore, delete it immediately */
        if (status.bad())
            delete elem;
    } else if (status.good())
        status = EC_MemoryExhausted;
    return status;
}

So, where is the bug?

[Michael Onken]

Hi Christian,

thanks for sharing and helping out.

At least in putAndInsertSint16Array "EC_MemoryExhausted" is also returned on illegal VRs - the EC_IllegalCall gets replaced if elem == NULL

Seems to me you are wrong here -- EC_IllegalCall gets not replaced since the status is only changed to MemoryExhausted if elem == NULL but also status.good() has to be true, which is not the case for EC_IllegalCall . This is the same for putAndInsertUint16Array() and putAndInsertSint16Array, both already in DCMTK 3.5.4 and in the snapshots. So I guess we must look at another place for the problem

In your case, I guess there has been an error in the function when actually instantiating the element with new(), which may indeed *could* be the same problem as the other two have. Well, let's see...

Best regards,
Michael

Edit: Jörg and also partially Christian is correct, for the Sint16 function that was only corrected after 3.5.4 release but is now fixed for some years

[insight]

OK, I see. Do you recommend using the snapshot instead of the release?

In my case the error was definitely the VR and not new(), but I am using 3.5.4.

[Jörg Riesmeier]

This depends of course on your particular requirements, but I don't think that the snapshot is more unstable than the latest release (3.5.4).
As always, the CHANGES file shows what has changed in the last couple of years ...

Btw, I was referencing the corresponding "commit" when I wrote that the bug has been fixed some time ago. Maybe, you missed that link.