We are currently facing a problem in a storescp-derivate (store SCP of K-PACS/iQ-VIEW) and files created by a FUJI CR (device model unknown). First of all, I know the file are corrupt and this should be corrected by the FUJI guys. Anyway ...
The server crashes abnormal during receiving the dataset. The SCP runs under Windows (XP in this case). The crash is reproducable and the call stack before the termination is:
- >IQSERVER.exe!operator new(unsigned int size=12) Line 64
>IQSERVER.exe!DcmList::insert(DcmObject * obj=0x014178e8, E_ListPos pos=ELP_next) Line 175 + 0x7 bytes
>IQSERVER.exe!DcmItem::insert(DcmElement * elem=0x014178e8, bool replaceOld=false, bool checkInsertOrder=true) Line 1249
>IQSERVER.exe!DcmItem::readSubElement(DcmInputStream & inStream={...}, DcmTag & newTag={...}, const unsigned long newLength=4294967295, E_TransferSyntax xfer=EXS_LittleEndianImplicit, E_GrpLenEncoding glenc=EGL_noChange, const unsigned long maxReadLength=4096) Line 883 + 0x19 bytes
>IQSERVER.exe!DcmItem::read(DcmInputStream & inStream={...}, E_TransferSyntax xfer=EXS_LittleEndianImplicit, E_GrpLenEncoding glenc=EGL_noChange, const unsigned long maxReadLength=4096) Line 974 + 0x24 bytes
>IQSERVER.exe!DcmDataset::read(DcmInputStream & inStream={...}, E_TransferSyntax xfer=EXS_LittleEndianImplicit, E_GrpLenEncoding glenc=EGL_noChange, const unsigned long maxReadLength=4096) Line 288 + 0x1f bytes
>IQSERVER.exe!DIMSE_receiveDataSetInMemory(T_ASC_Association * assoc=0x01414ed8, T_DIMSE_BlockingMode blocking=DIMSE_BLOCKING, int timeout=0, unsigned char * presID=0x013dde03, DcmDataset * * dataObject=0x013de01c, void (void *, unsigned long)* callback=0x0077a060, void * callbackData=0x013dddcc) Line 1695 + 0x26 bytes
The problem here is not that the stream content is corrupt (this should lead to an abortion) but that the implementation does not handle the situation and crashes.
Just wanted to report this ... I can also provide a sample dataset if you want. Maybe this report leads to a more robust implementation.