Slicer crashes on Big Sur after computer wakes up


I’m experiencing some strange behaviours with several apps after upgrading my 16 inch MBP to macOS 11.0.1. Slicer is one of them.

When I use an iPad as a second Sidecar display after the computer wakes from sleep Slicer crashes.

If it doesn’t crash - the UI becomes unresponsive and if scaled it looks like this

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.

Thanks for you reply @lassoan
Here’s the crash log

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

  1. 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

the app crashed with the following log

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.

Thanks for the additional information.

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.

1 Like