Hello,
I am experiencing repeated hard freezes in Dorico Pro 6.2.30.6245 on my Mac Studio. Dorico becomes completely unresponsive, shows the spinning beach ball, consumes substantial CPU, and its memory usage increases continuously until I force quit it.
System details:
-
Dorico Pro 6.2.30.6245, native ARM64
-
macOS 26.5.2, build 25F84
-
Mac Studio Mac14,13, 32 GB RAM
-
NotePerformer 5.1.2
-
Focusrite Scarlett 2i2 USB, 44.1 kHz
-
Dorico application UUID: 1758A1DB-7D0A-3534-87C9-111E98624585
The freeze has occurred repeatedly during normal work. On one occasion it appeared when I tried to minimise the Dorico window. On 19 August it appeared immediately after invoking Save.
However, the Dorico application log shows that the save operation itself completed successfully:
-
File.Save started at 16:06:12.623
-
the project, backup and autosave were written
-
File.Save completed at 16:06:13.153, after 530 ms
Dorico became unresponsive only afterwards.
I collected two Activity Monitor process samples from Dorico approximately one minute apart while it was frozen, as well as a simultaneous sample from VSTAudioEngine6.
Both Dorico samples show the main UI thread continuously executing the same internal Dorico call chain originating from:
QGuiApplicationPrivate::processMouseEvent
→ QWidget::event
→ internal Dorico functions
→ leaf addresses around Dorico +0x2c62b0c / +0x2c62b18
The thread is not waiting on file I/O, a system dialog, IPC or the audio engine. It appears to be running in a tight internal loop.
The macOS CPU resource report recorded:
-
75% average CPU usage over 120 seconds
-
memory growth from 1437.72 MB to 2229.91 MB
-
an increase of 792.19 MB in approximately two minutes
A separate incident from 18 August produced the identical Dorico call stack and the same leaf offsets, with:
-
71% average CPU usage
-
memory growth of 749.70 MB
The VSTAudioEngine6 sample taken during the latest freeze appears responsive and mostly idle. Its main thread is waiting normally for events, and its realtime and worker threads are waiting on their normal semaphores. There is no indication that Dorico is waiting for the audio engine or NotePerformer.
After restarting Dorico, the autosaved project opened successfully and was saved as a recovery copy, so the project data itself does not appear to be corrupted.
Could the development team please symbolicate the supplied stack addresses for build UUID 1758A1DB-7D0A-3534-87C9-111E98624585 and investigate the apparent infinite loop and memory leak in Dorico’s main UI thread?
I can provide the affected Dorico project privately to a member of the development team if required, but I would prefer not to upload the unpublished score publicly.
Thank you.