pycharm debug 卡在multiprocessing.server.manager

问题描述

使用 Python 3.8.0。
当我从这里的最后一行进入（或跳过）时，调试器分离（并继续该过程）（因此它在此之前遇到断点并且我正在逐步执行）：

class Whatever:
    def __init__(self, mydict):
        manager = multiprocessing.Manager()
        self._mydict = manager.dict(mydict)   # <---- step off here and the debugger "continues"
        # more code... 

如果我然后点击“暂停”按钮，它会停在multiprocessing/managers.py这一行：

def serve_forever(self):
        '''
        Run the server forever
        '''
        self.stop_event = threading.Event()
        process.current_process()._manager_server = self
        try:
            accepter = threading.Thread(target=self.accepter)
            accepter.daemon = True
            accepter.start()
            try:
                while not self.stop_event.is_set():   # <---- stops here,
                    self.stop_event.wait(1)   # <------ or here

相反，如果我在这段multiprocessing.Manager()代码之后放置一个断点，当断点被击中时，我将无法查看Whatever上面类的值- 相反，它只是无限期地显示“正在收集数据…”。它还为范围内但与该类或 Manager 实例无关的其他变量显示了这一点。似乎调试器卡住了。

我也可以通过回滚到 2019.1.4 确认这个早期版本没有这个问题，所以这是一个回归。

解决方法

English Version：The issue does not reproduce for me with “Gevent compatible” enabled in Preferences | Build, Execution, Deployment | Python Debugger.
中文版：在setting里直接搜索Gevent compatible， 开启这个选项即可解决该问题。

原因

The real reason is the fact that on Linux Manager uses a simple process fork under the hood and the debugger doesn’t handle this case correctly. That’s why only Linux users were affected.

The way to reproduce the issue on macOS:

from multiprocessing import Manager, set_start_method

if __name__ == '__main__':
    set_start_method('fork')
    manager = Manager()  # breakpoint, then run or step over
    print("Hello!")
    x = 42

This behavior feels wrong because of:

In reality, the child process doesn’t exit when its parent exits, so it should be debuggable even after its parent process no longer exists.
Another problem is caused by the fact that IDE sends SIGINT to stop a debuggee process. It causes troubles when the parent process exits before the debugger facilities are initialized in a child. In this case, SIGINT (which leads to the KeyboardInterrupt exception in Python) can’t be properly handled and weird error messages appear in the debugger console (see for example PY-37366).

参考链接

https://youtrack.jetbrains.com/issue/PY-37366
https://youtrack.jetbrains.com/issue/PY-37737