Request for MWorks to catch RecursionError raised in python

Hi,

Recently I ran into an issue where mworks server crashes, and in order to run another experiment I had to restart the mac. It was caused by a RecursionError in python. Would it be possible for MWorks to catch the error and print in console, like some other python errors? This would help debugging and also prevent me having to restart the machine.

In case it’s useful I’ve attached the error message after mworks server quit unexpectedly. Thank you for your time and help!

Thanks,
Ruidong

Attachment: Process__MWServer__372__error.txt (151 KB)

Hi Ruidong,

Apologies for the delayed reply. I was out on vacation for two weeks and am still catching up.

Recently I ran into an issue where mworks server crashes, and in order to run another experiment I had to restart the mac. It was caused by a RecursionError in python. Would it be possible for MWorks to catch the error and print in console, like some other python errors?

MWorks already logs any exceptions raised by Python code. (It can’t “catch” them, because Python exceptions don’t propagate outside of the Python interpreter.) From the crash report, it’s clear that unbounded recursion was the problem. However, it doesn’t appear that Python detected the recursion and raised RecursionError. Instead, it just kept recursing until the thread ran out of stack space, which caused MWServer to crash. MWorks doesn’t have any way to prevent that.

If the issue is that Python’s default recursion limit is too large, I suppose MWorks could call sys.setrecursionlimit to set it to a smaller value when initializing the interpreter. However, I don’t know how we’d decide what value to choose, other than picking an arbitrary value less than the default. If your Python code relies on deep recursion, maybe a better approach would be for it to call setrecursionlimit itself?

Cheers,
Chris

Hi Chris,

Thanks so much for your response! I’ve solved the specific issue and will
check for recursions if it ever happens again (hopefully not!)

Thanks,
Ruidong