- User Since
- Aug 1 2016, 12:10 PM (245 w, 18 h)
Thu, Apr 1
Thu, Mar 25
The topic came up in the Kaapana tech meeting again, because the current situation is causing problems there.
Mon, Mar 15
Not sure if this is related:
@gaoh thanks for pointing there, I will close this one as a duplicate
Another option for testing is to use dicomserver.co.uk , I think it is preconfigured in the Workbench. It's a public DICOM endpoint and the data there differs, but 5 min ago I was able to reproduce the crash with a retrieval from there. Just activate the checkbox in the MITK config table , query last month, select a few patients and retrieve. Worked for me to reproduce the crash.
Mar 12 2021
Feb 19 2021
Interesting catch. There is no call to regex_match in our code. If I understand it correctly the stack object is just created to check if an exception happens during construction, but maybe this is just another variant of the issue described for the library. A possible workaround could be to explicitly create and destroy the regex objects in our code, with explicit exception catching and re-throwing.
@norajitr maybe a bit more background on the ticket for you:
Feb 18 2021
I would like to have files versioned / with different names. If it's necessary to have a download link that doesn't change I can help with a script to create a "latest" link, had that for MITK nightlies back in the days
Feb 12 2021
Feb 10 2021
I tried running the Workbench on Linux both with valgrind as well as AdressSanitizer. Unfortunately there is a lot of noise from memory leaks and stuff, but I did not spot anything obvious which could be the cause.
Feb 9 2021
I did not dive into Windows APIs, so I just hope you know what you are doing ;)
I did some Googling, it seems that starting with 2019 release, Windows 10 has a UTF8 mode. It's a bit difficult to enable: "old" control panel -> region -> Administrative settings -> Change System locale -> Enable UTF8
That's a thorough dive in the topic ... Yes, toUtf8(), and nicely prints the correct Umlaut in the message box, telling you the file doesn't exist ;) I only had a quick glance around, and since a lot of stuff goes though ITK, and ITK decided to stay with local 8bit as far as I understand, I also think this would be the way to go. But I could really live with declaring this a "Known issue". Maybe something on the application user level would be nice, like
if toUtf8 != toLocal8Bit then show error
Feb 8 2021
Ok, the GDCM unicode windows fix was introduced in the 3.0 series: https://github.com/malaterre/GDCM/commit/d4dfa144b941c6cc4da87f9795f7f5aba2bb7481
Ok, I did look around a bit more. To summarize, I guess going for the "local 8bit representation" seems to be the most feasible way, since ITK also assumes this and I think we have a lot of ITK file handling code.
Ok, I debugged to SetFileName @floca mentioned, it gets called from GDCMImageIO::InternalReadImageInformation in ITK
Mostly as a reminder I tried on top of the branch above:
Oh no, I can remember similar issues with German Ubuntu and "Arbeitsfläche" ... Basically, CI clients should probably always have a path compontent like /bäh / included to catch new issues like this one, and build system stuff, which is also a candidate.
Feb 5 2021
I don't know why this was not linked automatically: https://phabricator.mitk.org/D469
I was hoping a bit to include it in the release, if the release would e.g. be used for kaapana containers for a longer time this could be helpful at some point. But of course it's not strictly necessary.
Valgrind shows some reading beyond memory boundaries, around mitkCoreActivator.cpp:129 and 218. Since it is the last line of all the AddPropertyPersistence calls there and all the creating of temp objects in there, I was wondering if it could be some reference to deleted temp objects issues. Just an idea.
It's the CoreActivator if I read this correcty:
And I just tested: as expected the unit tests do pass, I think it has to be a side effect of dlopen'ing the activator
@floca the comment I mention was written by you, line 112, any spontaneous idea?
In addition, suppressing deprecation warnings is in most cases no solution that lasts forever
Feb 1 2021
Jan 27 2021
Additional comment: the missing library doesn't prevent the Workbench from starting, but some/all DICOM functionality is missing which can be confusing
Ok, I just re-checked: Ubuntu 20.04 still has librwrap installed , so installer works. For Fedora there is no workaround , so either
Jan 25 2021
Jan 21 2021
@kislinsk anyone from the MITK CI team who could take over?
Jan 19 2021
Changes have landed . @neher could you test again using a nightly build?
Just submitted a Differential
Jan 15 2021
Thank. New command-line interface looks nice, but the challenge is where to put the credentials, especially if you want to put the script open source like in the Kaapana dockerfiles.
Jan 14 2021
Dec 2 2020
I contacted dcmqi upstream, thanks @fedorov for the quick reply.
PS: Chrome upload works but data doesn't show up in meta
Nov 30 2020
I tested with the latest develop:
WARNING: SliceThickness is present and is 1. using it! ERROR: JSON parameter file could not be parsed! You can validate the JSON file here: http://qiicr.org/dcmqi/#/validators Exception details (probably not very useful): LargestUInt out of Int range #11.518# ERROR: An error occurred while reading the DICOM Seg file: JSON Exception: file could not be read. #11.520# ERROR: Unknown read error occurred reading /home/nolden/Downloads/Lungs_seg_Left lung_1.dcm
Nov 27 2020
Nov 26 2020
I can confirm this fixes the issue, I can merge it tomorrow
Nov 24 2020
Nov 23 2020
I can confirm this patches fixes the problem. @kislinsk : hotfix oder feature branch?
diff --git a/Rendering/FreeType/vtkFreeTypeTools.cxx b/Rendering/FreeType/vtkFreeTypeTools.cxx index c54289dc60..03b899c4da 100644 --- a/Rendering/FreeType/vtkFreeTypeTools.cxx +++ b/Rendering/FreeType/vtkFreeTypeTools.cxx @@ -378,8 +378,7 @@ FTC_CMapCache* vtkFreeTypeTools::GetCMapCache() }
Nov 17 2020
Oct 20 2020
Ups ;) Replace with - or _?
Oct 19 2020
I was just about to add a note that there is the general question how to handle python in installers. I guess for just having the basic runtime available it would be ok to just load libpython3.so or libpython3.8.so and let the system take the right one from the right path. But on Windows I guess most people don't install Python in system locations. Anyway I think this could be fixed even with the current packaging if we need it for 2020, but I'm just reporting, no pressure from my side ;)
Oct 15 2020
Pushed new branch hotfix/T27887-fix-packaging-with-system-qt.
Oct 9 2020
OpenCV 3.4.11 (https://opencv.org/releases/)
Trivial should be:
PS: as an explanation, one theory is that the install-zip-package still references libraries from the build machine which causes the different behaviour
Sep 25 2020
@schererj we looked at the debug output, thanks. Unfortunately it seems to be complicated ... I would ask you to try another thing:
@kislinsk : I just noticed we had some earlier discussions and there is a branch which fixes two minor issues, not sure if relevant for option (1):
Sep 23 2020
This is resolved, dart client is running on my workstation
Clang 10 on Linux configuration is running now nightly on my desktop machine. "WorkbenchRelease" is green, "All" unfortunately hits an internal clang error . Setting this up on ubuntu would probably solve this, or some update on fedora.
Sep 11 2020
Just checked GDCM 3.0.7 if by chance the issue was fixed there, unfortunately not.
@schererj we just discussed this in the MITK meeting. Could you try something? It would be interesting to compare the outputs of
Since we have this task now I suggest to deactivate them "somewhere globally" and discuss later how to proceed. My guess would be it is quite some effort. Having tests for the generator, packging and the extension mechanism is very important I think, but I'm not sure what the current tests cover and if it's worth to fix.
Jul 30 2020
I'm setting up a clang 10 dart client right now. If that is submitting successfully I would close the task