The problem is also reproducible with the current master

Status update:

I can reproduce it with larger (patient) series, I generally can import mouse data without issue.
The problem can be reproduced in debug, provided another problem is dealt with. The attached patch comments out the progress information that causes an assert failure otherwise. I assume this is a separate problem that should be fixed.

The failure seems to be related with Qt events and usually happens somewhere deep in third party code where debugging is not available. To check whether CTK/Qt is genuinely at fault I tried to reproduce the issue using ctkDicomQueryRetrieve.

ctkDicomQueryRetrieve will freeze upon retrieving a data set, but if you wait for a bit it will finish correctly. The last lines of the log are:

D: ======================= END DIMSE MESSAGE =======================
E: Failed receiving DIMSE response: 0006:0317 Peer aborted Association (or never
connected)
No responses received at all! (at least one empty response always expected)
Retrieve success
I: Releasing Association
E: Association Release Failed: 0006:0303 DUL Finite State Machine Error: No acti
on defined, state 1 event 10
I: Aborting Association
E: Association Abort Failed: 0006:0303 DUL Finite State Machine Error: No action
defined, state 1 event 14
D: Cleaning up internal association and network structures

Once I do not run the dicomdirectorylistener in a separate thread it does not crash anymore. This can be achieved in a quick fix by commenting out [1]
m_DicomDirectoryListener->moveToThread(&m_Thread);

[1] http://mitk.org/git/?p=MITK.git;a=blob;f=Plugins/org.mitk.gui.qt.dicom/src/internal/QmitkDicomBrowser.cpp;h=e7b0486e28485782b997e78168f55efcfdf51da9;hb=HEAD#l121

User goch has pushed new remote branch:

bug-19446-dicom-q-r-crash

The above branch seems to fix the problem for me. It boiled down to threading issues with the directory listener on the one hand and the qt progress dialog on the other hand.

Could you test whether it works for you as well?

[8dc003]: Merge branch 'bug-19446-dicom-q-r-crash'

Merged commits:

2016-01-21 19:09:11 Caspar Goch [4c1a6f]
No longer use a separate thread for the directory listener

2016-01-21 19:07:52 Caspar Goch [543cb6]
Close progress dialog upon finished import

This should eliminate some thread based crashes due to the progress still
running in a separate thread.

2016-01-21 19:06:34 Caspar Goch [896077]
Remove duplicate connect

User goch has pushed new remote branch:

bug-19446-dicom-q-r-rebased

Tested 'bug-19446-dicom-q-r-crash'

To problems occure:

1. While the retrieve no info of some kind was displayed. Due to the removed the threading the application now just freezes and the user wonders what happens. I think we should display at least a "Please wait, while MITK is retreiving your date..." or something simelar.

2. It seems that not all requested data ends up in the local storage. I queried, selected a patient and ordered to retreive its data. The patient had 8 series, only 3 made it to the local DB but the process seems to be finished. Even if you explicitly select the series, the application seems to work, but no transfer into the local DB. The error was reproducible (even after restart).

It seems the problems with loading some of the image series and the resulting error messages in the console were due to an improper parsing of files to be opened.

In the method
void QmitkStoreSCPLauncher::OnReadyProcessOutput()
the console output of the SCP service is parsed and the file names to be loaded are extracted. When doing so the last directory separator is a backslash instead of a slash and the filename ends in "\r". After fixing both of these issues the fopen seems to work now without error.

User goch has pushed new remote branch:

bug-19446-parsing-problems-leading-to-corrupt-filenames

[70b53b]: Merge branch 'bug-19446-parsing-problems-leading-to-corrupt-filenames'

Merged commits:

2016-02-11 17:10:43 Caspar Goch [19d4ed]
Replace backslashes with slashes and remove carriage returns

patch provided via the users list concerning stdout/stderr output

Hi all,

This post provides a trivial one-line patch to the DICOM import plugin. It was crashing on me when retrieving files from a PACS. The problem seems to come from QmitkStoreSCPLauncher. The class tries to read the list of transferred files from stdout, but storescp sends messages to stderr. The path just asks Qt to merge both channels.

Regards

Manuel

diff --git a/Plugins/org.mitk.gui.qt.dicom/src/internal/QmitkStoreSCPLauncher.cpp b/Plugins/org.mitk.gui.qt.dicom/src/internal/QmitkStoreSCPLauncher.cpp
index b33e5c6..7ed5453 100644

• a/Plugins/org.mitk.gui.qt.dicom/src/internal/QmitkStoreSCPLauncher.cpp

+++ b/Plugins/org.mitk.gui.qt.dicom/src/internal/QmitkStoreSCPLauncher.c
+++ pp
@@ -31,6 +31,7 @@ See LICENSE.txt or http://www.mitk.org for details.
QmitkStoreSCPLauncher::QmitkStoreSCPLauncher(QmitkStoreSCPLauncherBuilder* builder)
: m_StoreSCP(new QProcess())
{
+ m_StoreSCP->setProcessChannelMode(QProcess::MergedChannels);

connect( m_StoreSCP, SIGNAL(error(QProcess::ProcessError)),this, SLOT(OnProcessError(QProcess::ProcessError)));
connect( m_StoreSCP, SIGNAL(stateChanged(QProcess::ProcessState)),this, SLOT(OnStateChanged(QProcess::ProcessState)));
connect( m_StoreSCP, SIGNAL(readyReadStandardOutput()),this, SLOT(OnReadyProcessOutput()));

Regarding the stdout/stderr output issue.

I have not encountered this problem, which OS are you using?

Win 7 64 bit, Visual Studio 2013, QT 5.4.1

User goch has pushed new remote branch:

bug-19446-dicom-qr-changes

[f7de9c]: Merge branch 'bug-19446-dicom-qr-changes'

Merged commits:

2016-03-04 16:20:48 Caspar Goch [d10d1d]
Use CTK progress bar instead of custom one

2016-03-04 16:20:22 Caspar Goch [6cfca6]
Merge StoreSCP output streams

The stream merge has been integrated. If any issues remain please comment on them in this bug, as I can not reproduce the problem on my system.

Also removed the custom retrieve dialog for now and reactivated the CTK one. The custom implementation did not appear directly after pressing the button, instead there was no GUI feedback. We might want to revisit redoing the progress dialog at a later date to make it more user friendly. However this could also be achieved by improving the CTK dialog.