StreamDeck-Shortcuts consumes 100% CPU time

[jokalode]

When entering the office first time in the morning, I have observed that the computer was very active, cooling fans spinning more than usual, while it should actually be sleeping. Checking CPU time it was StreamDeck-Shortcuts consuming 100 % CPU time. Killing the process, the computer went back to normal.

I can't remember having observed that behaviour while working on the computer. But I routinely build software on the computer. So it may just have escaped my notice.

Will observe if it is related to the sleep state, or not.

This relates to version 1.0.7.1.

[wesbland]

Same for me, though I don't see any logs that look relevant.

[SENTINELITE]

Hey, @wesbland!

Did you see this after the computer woke up from a rest state?

@jokalode, I've gotten this a few times over the past ~9 months. Super rare. Not sure how to debug it...

A restart always fixes it, but that's not ideal. 😅

Any more reports/info could be useful.

[wesbland]

I did have the computer asleep, but it didn't go away after waking up.

[SENTINELITE]

I did have the computer asleep, but it didn't go away after waking up.

Yeah, that's what I've experienced, too. Hm...

[jokalode]

I had this again yesterday. I applied the Xcode time profiler to the process, in the hope of finding some clue about what was going on. Can't say that I could make much sense of it at first glance, and I couldn't analyse in depth due time constraints of my own. But I noticed that some hashing was going on, and some CFSetGetValue was called many times ...

For a more structured analysis, I recorded a 30 s time profile when the process was seemingly ok, and idling happily. It looks like the following stacktrace.

StreamDeck-Shortcuts
start_wqthread	
_pthread_wqthread	
_dispatch_workloop_worker_thread	
_dispatch_workloop_invoke	
_dispatch_lane_invoke	
_dispatch_lane_serial_drain	
_dispatch_client_callout	
_dispatch_call_block_and_release	
nw_connection_add_read_request_on_queue	
nw_endpoint_handler_service_reads	
nw_flow_service_reads	
nw_framer_protocol_get_input_frames	
nw_socket_get_input_frames(nw_protocol*, nw_protocol*, unsigned int, unsigned int, unsigned int, nw_frame_array_s*)	
__recvmsg	

Makes sense: Sitting and waiting for message frames to arrive.

Now I am waiting for the event to occur again, to be able to have a look at the pathological case.

[SENTINELITE]

@jokalode Wow, thanks for this! I truly appreciate you digging into it, as I really have no idea how to debug it.

If you find more concrete info, perhaps we can find the culprit:

The plug-in uses the following package. if it has something to do with this, I'll make sure to submit a PR/big report.

Anyways, I'm willing to dig more into it, with some direction. I appreciate the you taking the time to reach out again!

[jokalode]

And here is a stacktrace for a pathological case:

125361	StreamDeck-Shortcuts
125361	start_wqthread	
125361	_pthread_wqthread	
125361	_dispatch_workloop_worker_thread	
125361	_dispatch_lane_invoke	
125361	_dispatch_lane_serial_drain	
125361	_dispatch_client_callout	
125361	_dispatch_call_block_and_release	
125361	thunk for @escaping @callee_guaranteed @Sendable (@guaranteed NSURLSessionWebSocketMessage?, @guaranteed Error?) -> ()	
125361	closure #1 in NSURLSessionWebSocketTask.receive(completionHandler:)	
125361	0x1082f7a80 // application
125361	protocol witness for Subscriber.receive(_:) in conformance Publishers.SubscribeOn<A, B>.Inner<A1>	
125361	Publishers.SubscribeOn.Inner.receive(_:)	
125361	Publishers.CompactMap.Inner.receive(_:)	
125361	protocol witness for Subscriber.receive(_:) in conformance Publishers.TryMap<A, B>.Inner<A1>	
125361	Publishers.TryMap.Inner.receive(_:)	
125361	protocol witness for Subscriber.receive(_:) in conformance Publishers.Catch<A, B>.Inner<A1>.UncaughtS	
125361	Publishers.Catch.Inner.UncaughtS.receive(_:)	
125361	Publishers.Catch.Inner.receivePre(_:)	
125361	Publishers.CompactMap.Inner.receive(_:)	
125361	protocol witness for Subscriber.receive(_:) in conformance Subscribers.Sink<A, B>	
125361	Subscribers.Sink.receive(_:)	
125361	0x1082ef030 // application	
125361	0x1082e9f80 // application
125361	0x1082ea450 // application
125361	0x1082a6c80 // application
125361	0x1082b8d00 // application
125361	0x1082ba240 // application
125130	-[NSConcreteTask waitUntilExit]	
116946	CFRunLoopRunSpecific	
63386	__CFRunLoopCopyMode	
36272	CFSetGetValue	
23572	CFBasicHashFindBucket	
6682	CFEqual	

Until _dispatch_call_block_and_release we see the same call stack as in the healthy sample, which was waiting for message frames to arrive. So I guess that a message frame did arrive, and this pathological behaviour starts when or after processing that message. This assumption is backed by closure #1 in NSURLSessionWebSocketTask.receive.

Then we see the Combine framework in action: publishing, compact-mapping, try-mapping, catching, compact-mapping again, finally delivering to the Sink.

The pathological behaviour starts after [NSConcreteTask waitUntilExit]: There the application gets into an endless loop. As far as I can see, this concerns the CoreFoundation framework. Misconfigured run loop mode? Fails on something and falls back to itself? A repeating timer that reschedules itself immediately? I can only guess.

@SENTINELITE, hope this gives you an idea where to look. In the meantime, I'll try to build a local version.

[jondkinney]

Similar issue here