Qudi crashes if a GUI module is loaded via RPyC. There is a warning from the OS (Ubuntu 22.04.4LTS) that __main__.py is not responding. The module manager and the loaded GUI module both are unresponsive and the user has to forcefully close Qudi.
When does the bug occur?
When loading a GUI module via RPyC. Note that loading logic and hardware modules (in my limited testing of a few modules) seems to work fine. Also in most cases, the GUI window that opens is just a blank screen but for some reason pulsed_gui appears to load properly (including the popup window asking to do a benchmark) but then immediately becomes unresponsive.
How do we replicate the issue?
Launch Qudi (optionally in debug mode, doesn't seem to matter)
Load the default dummy config (have not tested this on other configs)
In the iPython window, load any GUI module (e.g. ODMR GUI) using qudi.module_manager.activate_module('odmr_gui')
Qudi crashes
Expected behavior
The GUI should load properly. Qudi should not become completely unresponsive.
Relevant log output
2024-08-06 10:28:56 info qudi.Qudi Starting qudi in debug mode...
2024-08-06 10:28:56 debug qudi.core.threadmanager Creating thread: "remote-modules-server".
2024-08-06 10:28:56 debug qudi.core.threadmanager Creating thread: "local-namespace-server".
2024-08-06 10:28:56 info qudi.Qudi Applying configuration from "/home/prithvi/qudi/config/default.cfg"...
2024-08-06 10:28:56 info qudi.core.servers Starting RPyC server "local-namespace-server" on [localhost]:18861
2024-08-06 10:28:56 info qudi.core.servers Starting RPyC server "remote-modules-server" on [localhost]:12345
2024-08-06 10:28:56 debug qudi.core.servers local-namespace-server: protocol_config is {'allow_all_attrs': True, 'allow_setattr': True, 'allow_delattr': True, 'allow_pickle': True, 'sync_request_timeout': 3600, 'logger': <Logger QUDINAMESPACE/18861 (warning)>}, authenticator is None
2024-08-06 10:28:56 info qudi.Qudi Qudi configuration complete!
2024-08-06 10:28:56 debug qudi.core.servers remote-modules-server: protocol_config is {'allow_all_attrs': True, 'allow_setattr': True, 'allow_delattr': True, 'allow_pickle': True, 'sync_request_timeout': 3600, 'logger': <Logger REMOTEMODULES/12345 (warning)>}, authenticator is None
2024-08-06 10:28:56 info qudi.core.gui.gui Activating main GUI module...
2024-08-06 10:28:57 info qudi.core.gui.main_gui.main_gui.QudiMainGui IPython kernel for qudi main GUI successfully started.
2024-08-06 10:28:57 info qudi.Qudi Initialization complete! Starting Qt event loop...
2024-08-06 10:28:57 info qudi.core.services Client connected to local module service from [127.0.0.1]:51246
2024-08-06 10:29:13 info qudi.core.modulemanager Activating gui module "odmr.odmrgui.OdmrGui"
2024-08-06 10:29:13 info qudi.core.modulemanager Activating logic module "odmr_logic.OdmrLogic"
2024-08-06 10:29:13 info qudi.core.modulemanager Activating hardware module "dummy.finite_sampling_input_dummy.FiniteSamplingInputDummy"
2024-08-06 10:29:13 info qudi.core.modulemanager Activating hardware module "dummy.microwave_dummy.MicrowaveDummy"
2024-08-06 10:29:13 debug qudi.core.threadmanager Creating thread: "mod-logic-odmr_logic".
Additional Comments
This bug has been observed on Ubuntu 22.04.4LTS and on Windows 10. Have not tested on other platforms.
Version
Development
What is affected by the bug?
Qudi crashes if a GUI module is loaded via RPyC. There is a warning from the OS (Ubuntu 22.04.4LTS) that
__main__.py
is not responding. The module manager and the loaded GUI module both are unresponsive and the user has to forcefully close Qudi.When does the bug occur?
When loading a GUI module via RPyC. Note that loading logic and hardware modules (in my limited testing of a few modules) seems to work fine. Also in most cases, the GUI window that opens is just a blank screen but for some reason
pulsed_gui
appears to load properly (including the popup window asking to do a benchmark) but then immediately becomes unresponsive.How do we replicate the issue?
qudi.module_manager.activate_module('odmr_gui')
Expected behavior
The GUI should load properly. Qudi should not become completely unresponsive.
Relevant log output
Additional Comments
This bug has been observed on Ubuntu 22.04.4LTS and on Windows 10. Have not tested on other platforms.
Contact Details
No response