MWorks becoming unresponsive during experiment

Support
1

Hi Chris,

Hope this email finds you well!

I’ve been encountering repeated issues with MWorks becoming unresponsive during an experiment and was wondering if you might have suggestions for troubleshooting it.

The issue has occurred several times over the past two days:

  • Yesterday, macOS reported “Your system has run out of application memory” during the experiment. I had to force quit several applications, including MWorks.

  • Today, I restarted the computer before the session, but after about 30 minutes both MWorks Server and Client showed “Not Responding.” The experiment itself (stimulus, reward delivery) appeared to continue running normally in front of the monkey.

  • After restarting MWorks, the issue occurred again after a while. This time, only MWorks Client became unresponsive. Server remained responsive, the experiment continued running, and the stimulus mirror window continued updating.

I’m running macOS Tahoe 26.3.1 on a Mac Studio (Apple M2 Max chip) with 32 GB RAM.

I previously ran this exact same experiment on this computer without these issues. I stopped running experiments for about 1.5 months, and yesterday and today were my first sessions after that break. I haven’t intentionally made any major changes to the experiment during that time. But I realized the automatic system update is turned on for this computer.

I tried keeping Activity Monitor open today to track memory usage, but during the experiment it does not update, so I wasn’t able to determine the memory usage immediately before the problem.

Yoon mentioned that memory issues can occur if too many image stimuli are loaded into GPU memory upfront and suggested using the deferred parameter to load stimuli on the fly. The current experiment does load 1200 image stimuli at the beginning. Do you think stimulus loading could be related to these issues, or is there anything else you would recommend checking given that the same experiment previously ran without problems?

Here I attach my experiment code. I’m happy to share other logs if needed. Thank you very much!

Best,
Chuiwen

4

Hi Chuiwen,

This doesn’t sound like a problem you’d see from loading too many stimuli. My first thought is that your experiment may be generating an excessive number of events, and the server and client are getting bogged down trying to process them all. Let me take a look at your experiment and see if I can spot any issues.

Cheers,
Chris

5

Hi Chuiwen,

Your experiment code all looks fine to me. Are you using MWClient’s MATLAB or Python windows? If so, can you share the scripts you’re running? It’s possible something is going wrong there.

Since your Mac has already updated itself automatically, it would probably be wise to update it to the latest version of Tahoe (currently 26.6.1), in case there’s a now-fixed OS bug that’s causing this issue. I don’t expect it will make any difference, but it’s worth trying.

I tried keeping Activity Monitor open today to track memory usage, but during the experiment it does not update, so I wasn’t able to determine the memory usage immediately before the problem.

You mean the amount of memory used by MWClient and MWServer stayed exactly constant the whole time you were looking? That’s strange. While the memory usage should be constant on average, it should vary a bit from update to update. Maybe you need to increase Activity Monitor’s update frequency (e.g. set View → Update Frequency to “Very often”).

One other thing to check: Are there any crash reports for MWClient or MWServer associated with the times you’ve had to force quit them? To check, open the Console application (/Applications/Utilities/Console.app). In the sidebar, select Crash Reports. In the list that appears, find any with MWClient or MWServer in the name. If you see any, can you send them to me? You should be able to drag and drop them in to an email message.

Thanks,
Chris