When I was debugging a similar issue for Sublime Text disabling gpu buffering helped preventing unresponsive UI.
As far as I tried to debug the issue in slicer I can only replicate the crash if the python interpreter is present in the app layout. I have the system crash log if it might help.
I’ve tried to change GPU raycasting to CPU raycasting in the application setting but that didn’t help.
Is there any way to disable GPU buffering of some sort like I did to solve the issue in Sublime?
Maybe any other advice on how to debug this?
Thanks for reporting this. We have had 2 reports of Slicer crashing on mac after coming back from sleep, but they were all isolated, non-reproducible cases, so we could not act on them. It is great that you have a way to reproduce this problem because it means that we can fix it. I’ve added a bug report for this:
As a first step, could you send the crash report that macOS generates? Especially the call stack (beginning of the file) is informative, because it tell which library is the culprit (almost surely Qt) and which method. We can then find what other application developers did, when they encountered this problem and adopt one of those solutions.
Thank you, this is interesting. It seems to be an error in the DICOM database. Can you try if it makes a difference if you create a new DICOM database? (in DICOM module)
Thanks for the suggestion @lassoan. The main “non-standard” thing with the dicom database is that it frequently contains images that have non-ascii characters in the “patient name” tag (cyrillic). I saw earlier that some programs don’t yet have unicode support, for example ITK-Snap can’t load images from paths that contain non-ascii characters.
I don’t usually use DICOMs as I try to stick to Nifti files in general, but I did some more debugging with the DICOM database.
Here’s what I’ve found
I have an older database in the main folder where the database is expected to be
So I was using a proper external display, I’ve upgraded the dicom database and everything was fine. No issues.
But then I recalled that the issue appeared when I used an iPad as a sidecar display. I’ve connected the iPad to the mac, and after I received an absolutely meaningful error notification from macOS
So I can replicate the issue only with an iPad as a sidecar display, and not with a physical external or internal display
I personally am fine just knowing these limitations and I don’t know if many slicer users use sidecar. If this is an issue that might influence all mac users in the future, maybe it is worth looking into it. If it only relates to sidecar - I personally doubt that many users will run into it.
Current stable release fully supports international characters (utf8) everywhere. If you run into any issues then let us know.
The crash in this latest report seems to be due to a low level display driver or Qt bug that probably Apple or Qt developers will fix in the future. We could report the error and nag developers to make it happen faster, but it is probably not worth the effort.