После запуска определенного старого проекта macOS (который не затрагивался в течение двух лет) из Xcode 11 на Catalina приложение потребляет примерно 100% процессорного времени и не отвечает (надувной мяч).
Я проверил, что происходит, и кажется, что приложение занято выполнением методов NSView, связанных с прогоном l oop (?), Случайная трассировка стека основного потока после приостановки выполнения выглядит следующим образом:
#0 0x00000001006ff21a in pthread_main_np ()
#1 0x00000001006fe898 in checker_c ()
#2 0x00000001006fd6d1 in trampoline_c ()
#3 0x00000001006d55fb in handler_start ()
#4 0x00007fff2df6c9e8 in -[NSCell resetCursorRect:inView:] ()
#5 0x00007fff2df6c907 in -[NSControl resetCursorRects] ()
#6 0x00007fff2de7d182 in -[NSView(NSInternal) _updateTrackingAreasWithInvalidCursorRects:] ()
#7 0x00007fff2de7d771 in -[NSView(NSInternal) _updateTrackingAreasWithInvalidCursorRects:] ()
#8 0x00007fff2de7d771 in -[NSView(NSInternal) _updateTrackingAreasWithInvalidCursorRects:] ()
#9 0x00007fff2de7d771 in -[NSView(NSInternal) _updateTrackingAreasWithInvalidCursorRects:] ()
#10 0x00007fff2de7d771 in -[NSView(NSInternal) _updateTrackingAreasWithInvalidCursorRects:] ()
#11 0x00007fff2de7d771 in -[NSView(NSInternal) _updateTrackingAreasWithInvalidCursorRects:] ()
#12 0x00007fff2de7cc69 in _NSWindowDisplayCycleUpdateStructuralRegions ()
#13 0x00007fff2de7749d in __NSWindowGetDisplayCycleObserverForUpdateStructuralRegions_block_invoke ()
#14 0x00007fff2de6f621 in NSDisplayCycleObserverInvoke ()
#15 0x00007fff2de6f1e8 in NSDisplayCycleFlush ()
#16 0x00007fff3c3cb112 in CA::Transaction::run_commit_handlers(CATransactionPhase) ()
#17 0x00007fff3c3c9e64 in CA::Transaction::commit() ()
#18 0x00007fff2df2be87 in __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke ()
#19 0x00007fff2e64777d in ___NSRunLoopObserverCreateWithHandler_block_invoke ()
#20 0x00007fff30bc40ee in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#21 0x00007fff30bc4014 in __CFRunLoopDoObservers ()
#22 0x00007fff30bc370b in __CFRunLoopRun ()
#23 0x00007fff30bc2bd3 in CFRunLoopRunSpecific ()
#24 0x00007fff2f71965d in RunCurrentEventLoopInMode ()
#25 0x00007fff2f7192a9 in ReceiveNextEventCommon ()
#26 0x00007fff2f719127 in _BlockUntilNextEventMatchingListInModeWithFilter ()
#27 0x00007fff2dd8aeb4 in _DPSNextEvent ()
#28 0x00007fff2dd89690 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] ()
#29 0x00007fff2dd7b3ae in -[NSApplication run] ()
#30 0x00007fff2dd4d775 in NSApplicationMain ()
#31 0x00000001000089b2 in main at /Users/Developer/Documents/Projekte/3d-viz-tool/src/main.m:12
#32 0x00007fff6821f7fd in start ()
Трассировка стека всего через несколько секунд будет выглядеть аналогично вершине стека. Кажется, что программа застряла со сбросом курсора, потому что адреса вызовов метода _updateTrackingAreas ... остаются прежними.
Других потоков со значительным временем ЦП нет, основной расходует почти все ресурсы ЦП, но память остается flat.
У меня очень мало опыта работы с фреймворками и особенностями macOS, и я надеюсь, что такое поведение легко объяснимо ...