Extension Wizard - file open dialogs hang UI for several seconds

When I first tried to run it only offered cancel or move the app to the trash. I cancel, and then in the System Preferences under Security & Privacy there was a button added to enable running the app. After that it worked.

Could everybody with a Mac report the following for a recent Slicer preview release:

  • MacOSX version, Slicer version
  • application startup time
  • time to show a file selection dialog (menu: File / Add data / Choose file to add)
  • time to show Extension wizard window

Thank you!

OK, I found out something rather odd. This is with the 11-7 slicer nightly build (downloaded Saturday PM).

Test:

  1. Run slicer
  2. Go to screen capture module
  3. Hit … for dialog box to pick output directory.

When I run slicer by double-clicking on the app, the dialog box always freezes halfway through its “zoom up” process. It hangs the window manager completely for several seconds. It will also sometimes hang the WM after it is up.

When I open a terminal window and run slicer from the command line (i.e., cd Desktop/Slicer.app/Contents/MacOS; ./Slicer) I never get these hangs.

Could it be some environment variable or path difference between running from the WM by double-clicking vs running on the command line?

This is MacOS 10.14.4.

This freeze of the window manager is due to the tccd system process hanging for tens of seconds. This is what we try to fix.

Do you experience this issue with Slicer built with Qt-5.12.5?

I was not able to run the 5.12.5 slicer because (I think) it’s built for 10.15, and I’m running 10.14.4.

Also, I thought the tccd problem was only referring to 10.15.

You can use Instruments (I think it comes with xcode) to see what’s happening while the file dialog hangs. Maybe you can also try the package that @Sunderlandkyl built.

That’s the one I can’t run (the one @Sunderlandkyl built with 5.12.5).

On 10.14.4, if I put Slicer into the “it can control your machine” list in security settings, I do not get the dialog box hang. I mistakenly thought that was a 10.15-only issue.

1 Like

Here are some nightly stats:

  • MacOS: 10.14.6
  • Slicer Nightly (2019-11-09)
  • Startup: 11.0s
  • File dialog: 0.0s
  • Extension manager: 6.1s
1 Like

This is a very important finding.

@Sunderlandkyl do you see any difference in file dialog display time if you change security settings for Slicer application?

Slicer is not in the list of apps that can “control your computer”, and I am unable to add it.

I restarted the Mac, and now I’m seeing different behavior (same Nightly as before 2019-11-09):
Startup: Hangs OS for ~33.4s on startup (total startup time (45.5s).
File dialog: 0.0s
Extension manager: Hangs OS for 56.4s.

Trying to determine why I can’t add security options for Slicer.

I have a similar issue. Slicer shows up in the accessibility list, but I cannot check it. I also reinstalled, removed Slicer, but that didn’t change anything.

1 Like

Andras and I did some more digging into this issue.

Logged tccd using this command:

log stream --debug --predicate ‘subsystem == “com.apple.TCC”’

During startup, there is a 50sec window where tccd is presumably checking the application signature:

2019-11-13 12:41:30.733517-0500 0x7694f Info 0xa9379 199 0 tccd: [com.apple.TCC:access] adhoc signed StaticCode :0x7fa6d33950e0 START
2019-11-13 12:42:23.224389-0500 0x7694f Info 0xa9379 199 0 tccd: [com.apple.TCC:access] adhoc signed StaticCode :0x7fa6d33950e0 END

This seems to be the main cause of the hang in MacOS 10.14 for many unsigned applications.

Creating an ad-hoc signing with the following command allows Slicer to open without the delay:

codesign --force --deep -s - /Applications/Slicer.app/Contents/MacOS/Slicer

1 Like

@che85 @hherhold @pieper could you check if using the codesign command above fixes the temporary system hang for you?

Yep - works. (Sorry for slow reply.)

Just tried on 11-18 build, freshly downloaded. Dialog box hang, then did codesign, then dialog box does not hang.

2 Likes

@jcfr, could we try to do such self-signing with some default (non-trusted) signature? TCC does not seem to delay requests from executables that are at least self-signed.

Self-signing may not work between different computers/users (maybe TCC only accepts self-signed executables from the current user?), but it might worth a try, as it is a simpler process than accessing the official Kitware signing computer.

could we try to do such self-signing with some default (non-trusted) signature?

While creating the self-signed certificate, worth noting that the following message is reported:

image

@lassoan @pieper @rkikinis @hherhold A self-signed package corresponding to the most recent nightly is now available for download at https://data.kitware.com/#item/5dddb66daf2e2eed3533ec79

Note that the signing was manually done

On Mac Catalina 10.15.1 : Both the dmg and slicer require opening with a right mouse click, but do not require going to preference/security. Workable.

I did some testing using various versions with commands like this:

time /Applications/"Slicer 2.app"/Contents/MacOS/Slicer --python-code "exit()"

All the release builds, both 4.10.2 and the nighlies and the new self-signed version from Jc complete in about 10-12 seconds. My local debug build takes about 30 seconds for the same command line, whether I self-sign it or not.

I didn’t see anything particularly informative in the log stream command.

1 Like

@jcfr I can confirm that the signed package doesn’t cause the hang. The only regression is that the installer requires a right-click to open.

1 Like