Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads
Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads
- Subject: Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads
- From: Allan Odgaard via Cocoa-dev <email@hidden>
- Date: Fri, 24 Apr 2020 11:13:19 +0700
On 24 Apr 2020, at 9:51, Gary L. Wade wrote:
Have you tried a speed check with just iCloud turned off but internet
on?
I have tried with iCloud disabled, internet disabled, and SIP disabled.
Only the latter two removes the delay. Also, the issue happens for
~/Downloads which is not an iCloud folder.
Furthermore, the stack dump seems fairly clear about what goes on.
For the records, I’m reposting my findings here with stack dump.
This is actually from Transmission.app, in Preferences you can configure
download folders, so I selected ~/Documents, ~/Downloads, and ~/Desktop,
which are the 3 “protected” folders. I then ran a spindump when
opening Preferences, which has to obtain display name and icon for these
folders (to show in the UI), which results in 620 ms spent in
NSWorkspace’s iconForFile: (getattrlist).
62 -[NSWorkspace iconForFile:] + 80 (AppKit + 3229058)
[0x7fff32ee1582]
62 -[NSWorkspace _iconForURL:] + 100 (AppKit + 3229205)
[0x7fff32ee1615]
62 _GetIconRefFromURL + 26 (LaunchServices + 233122) [0x7fff370edea2]
62 BindingManager::CreateWithURL(__CFURL const*, bool) + 28
(LaunchServices + 233204) [0x7fff370edef4]
62 BindingBlueprint::BindingBlueprint(__CFURL const*) + 78
(LaunchServices + 233350) [0x7fff370edf86]
62 BindingBlueprint::copyURLProperties(__CFURL const*) + 50
(LaunchServices + 233496) [0x7fff370ee018]
62 CFURLCopyResourcePropertiesForKeys + 111 (CoreFoundation + 555324)
[0x7fff3599493c]
62 _FSURLCopyResourcePropertiesForKeysInternal(__CFURL const*,
__CFArray const*, void*, __CFError**, unsigned char) + 1110
(CoreServicesInternal + 60765) [0x7fff4ecb0d5d]
62 prepareValuesForBitmap(__CFURL const*, __FileCache*,
_FilePropertyBitmap*, __CFError**) + 363 (CoreServicesInternal + 17604)
[0x7fff4eca64c4]
62 __getattrlist + 10 (libsystem_kernel.dylib + 5746)
[0x7fff6fa19672]
*62 hndl_unix_scall64 + 22 (kernel + 819718) [0xffffff80002c8206]
*62 unix_syscall64 + 647 (kernel + 7894519) [0xffffff80009875f7]
*62 getattrlist + 136 (kernel + 3512472) [0xffffff8000559898]
*62 ??? (kernel + 3512820) [0xffffff80005599f4]
*62 ??? (kernel + 3501529) [0xffffff8000556dd9]
*62 ??? (kernel + 3490836) [0xffffff8000554414]
*62 mac_vnode_check_access + 154 (kernel + 9093082)
[0xffffff8000aabfda]
*62 hook_vnode_check_access + 167 (Sandbox + 39552)
[0xffffff7f823a7a80]
*62 sb_evaluate + 5004 (Sandbox + 67658) [0xffffff7f823ae84a]
*62 approval_response_wait + 142 (Sandbox + 154851)
[0xffffff7f823c3ce3]
*62 __WAITING_ON_APPROVAL_FROM_SANDBOXD__ + 23 (Sandbox + 155134)
[0xffffff7f823c3dfe]
*62 ??? (kernel + 6855402) [0xffffff8000889aea]
*62 thread_block_reason + 175 (kernel + 1317935) [0xffffff8000341c2f]
*62 ??? (kernel + 1324017) [0xffffff80003433f1]
*62 machine_switch_context + 200 (kernel + 2388456)
[0xffffff80004471e8]
Looking at sandboxd, it has 3 queues spending respectively 150, 160, and
310 ms in TCCAccessPreflightWithAuditToken (so total time spent there is
620 ms), which I would guess is processing Transmission’s request for
reading the extended attributes for the 3 paths.
But sandboxd itself does tccd_send_message, so it seems to call upon the
tccd daemon.
There are two tccd instances running on my system, each have two queues
with 150 ms spent in SecCodeCheckValidityWithErrors (so a total of 600
ms spent in tccd).
This code though again seems rely on another process by calling:
securityd_send_sync_and_do (which does XPC).
But I can’t find out which process it communicates with. I don’t
know if this could be launched-on-demand and therefore not part of the
spindump report?
But to summarize, first call of getattrlist/getxattr for a protected
folder seems to trigger application signature validation (makes sense),
which, at least on my system, appears to involve network access,
reminiscent of what goes on with execve().
Given the above, I don’t think anyone can dispute that this is what
goes on, and it would be extremely strange if this is not “by
design”.
What might be a bug is that the check does network access, but you
don’t just put such code in by mistake, so obviously there must be
certain times where it needs network access, and as demonstrated with
execve(), Apple is not shy of making low-level system APIs contact
Apple’s servers as part of their SIP.
The million dollar question is now: What are the conditions under which
it must have network access? and/or why does it seem to trigger all the
time on my system?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden