Conquest does not accept US problem.

    I am trying to send a US cardiac study with a couple of lengthy cine sequences. I believe that the longest is about 200meg in size. I get the following error sequence followed by a "dead server restart", debug level 4. The machine is a GE Logiq e, about 6 months old.


    [FAIRLIGHT] UPACS THREAD 74: STARTED AT: Fri Nov 30 08:05:58 2007
    [FAIRLIGHT] A-ASSOCIATE-RQ Packet Dump
    [FAIRLIGHT] Calling Application Title : "FAIRGEUS2 "
    [FAIRLIGHT] Called Application Title : "FAIRLIGHT "
    [FAIRLIGHT] Application Context : "1.2.840.10008.3.1.1.1"
    [FAIRLIGHT] Number of Proposed Presentation Contexts: 5
    [FAIRLIGHT] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.7"
    [FAIRLIGHT] Presentation Context 1 "1.2.840.10008.5.1.4.1.1.6.1"
    [FAIRLIGHT] Presentation Context 2 "1.2.840.10008.5.1.4.1.1.3.1"
    [FAIRLIGHT] Presentation Context 3 "1.2.840.10008.5.1.4.1.1.6"
    [FAIRLIGHT] Presentation Context 4 "1.2.840.10008.5.1.4.1.1.3"
    [FAIRLIGHT] Server Command := 0001
    [FAIRLIGHT] Message ID := 002e
    [FAIRLIGHT] 0000,0002 28 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.3.1"
    [FAIRLIGHT] 0000,0100 2 US CommandField 1
    [FAIRLIGHT] 0000,0110 2 US MessageID 46
    [FAIRLIGHT] 0000,0700 2 US Priority 0
    [FAIRLIGHT] 0000,0800 2 US DataSetType 0
    [FAIRLIGHT] 0000,1000 50 UI AffectedSOPInstanceU "1.2.840.113619.2.224.3420688.1194391281.0.386.512"
    [FAIRLIGHT] 0002,0010 19 UI TransferSyntaxUID "1.2.840.10008.1.2.1"
    [FAIRLIGHT] Written file: F:\fairdicom\36174\1.2.840.113619.2.224.3420688.1194391281.0.385_0001_000001_11962778131081.dcm
    [FAIRLIGHT] UPACS THREAD 71: ENDED AT: Fri Nov 30 08:08:33 2007
    [FAIRLIGHT] UPACS THREAD 71: TOTAL RUNNING TIME: 591 SECONDS
    [FAIRLIGHT] ExportConverter0.0: forward F:\fairdicom\36174\1.2.840.113619.2.224.3420688.1194391281.0.385_0001_000001_11962778131081.dcm to FAIRLIGHT5
    [FAIRLIGHT] Mirror copy: \\n5200\usbhdd\fairdicom\36174\1.2.840.113619.2.224.3420688.1194391281.0.385_0001_000001_11962778131081.dcm
    [FAIRLIGHT] [DecompressImage]: internal decompressor does not support color jpeg, using external decompressor
    [FAIRLIGHT] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
    [FAIRLIGHT] 0000,0100 2 US CommandField 48
    [FAIRLIGHT] 0000,0110 2 US MessageID 7
    [FAIRLIGHT] 0000,0800 2 US DataSetType 257
    [FAIRLIGHT] 9999,0400 6 UN "silent"
    [FAIRLIGHT] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
    [FAIRLIGHT] 0000,0100 2 US CommandField 48
    [FAIRLIGHT] 0000,0110 2 US MessageID 7
    [FAIRLIGHT] 0000,0800 2 US DataSetType 257
    [FAIRLIGHT] 9999,0400 6 UN "silent"
    [FAIRLIGHT] ***VR:ReAlloc out of memory allocating 355622400 bytes
    [FAIRLIGHT] ***A fatal error occurred (out of memory) - closing server


    It seems like the external decompressor is running out of memory? Allocate 355gigs of memory, ha ha. Any idea on what is happening here and how to fix it? Actually the first longest cine seems to make it to conquest, the second and subsequent images are not present. Conquest reports the first cine sequence is present at 118 meg. The second image in the series is just a single color doppler image.
    This machine has been sending a variety of studies including echocardiograms for months now without any problem sending. I wonder if one of the sequences is not corrupted. But, the error seems to occur during decompression for verification so I guess it must be a decompressor failure, right?


    Thanks,
    Leszek

    hmm, I rebooted the logiq e and got the following message from conquest during the logiq e boot.


    [FAIRLIGHT] UPACS THREAD 1: STARTED AT: Fri Nov 30 08:13:40 2007
    [FAIRLIGHT] Calling Application Title : "FAIRGEUS2 "
    [FAIRLIGHT] Called Application Title : "FAIRLIGHT "
    [FAIRLIGHT] Application Context : "1.2.840.10008.3.1.1.1"
    [FAIRLIGHT] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.7"
    [FAIRLIGHT] Presentation Context 1 "1.2.840.10008.5.1.4.1.1.6.1"
    [FAIRLIGHT] Presentation Context 2 "1.2.840.10008.5.1.4.1.1.3.1"
    [FAIRLIGHT] Presentation Context 3 "1.2.840.10008.5.1.4.1.1.6"
    [FAIRLIGHT] Presentation Context 4 "1.2.840.10008.5.1.4.1.1.3"
    [FAIRLIGHT] *** Association rejected: you may need to add the listed presentation context as sop to dgatesop.lst
    [FAIRLIGHT] UPACS THREAD 1: ENDED AT: Fri Nov 30 08:18:40 2007
    [FAIRLIGHT] UPACS THREAD 1: TOTAL RUNNING TIME: 300 SECONDS


    All these SOP are correct for multiframe US storage and present in my dgatesop.lst (I opened the list and confirmed). Why the rejection? Is this related to the previous error?
    To clarify, I rebooted the GE US after the conquest failure of the previous post. The US pauses for a long time at boot and I see the above error in conquest...


    Leszek


    Leszek

    The first one: the jpeg sequence is decompressed externally and is then 355 MB. It fails to allocate that amount when loading the decompressed image into memory (it resides in printer_files, and is not deleted upon a crash), so you can check that. You can also run dgate --checklargestmalloc: to test the amount of memory.


    Basically, the problem is that these long JPEG sequences should not be decompressed as they grow too big: we use compression mode nj (nki or jpeg compression) for that purpose. It may also be useful to add uj (uncompressed or jpeg) to solve these issues.


    No clue what the second problem is, I guess a missing transfer syntax.


    Marcel

    Ok. There is a ~355meg file in printer_files. The __checklarestmalloc: yields


    [FAIRLIGHT] Server command sent using DGATE -- option
    [FAIRLIGHT] Largest malloc = 730 MB


    I guess I should set up a noncompressed instance of conquest and route that machine to it.


    I wonder why this problem never arose before. The machine has 2gb physical memory.


    Leszek

    Hi Leszek,


    The crash actually happens during decompression for the forwarding, probably the object is in memory twice. Maybe set things up to forward these with jpeg compression (i.e. without change). Could be that previous versions also had out of memory here but silently failed.


    By the way, I am working on a 64 bit version to alleviate memory limits.


    Marcel

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login