[Bug] Issues with Odmr & Pulsed GUI after deactivating their logic modules.

[astropiuu]

Version

current main

What is affected by the bug?

Qudi crashes when relaunching the Odmr GUI module after deactivating or clearing status variables for the Odmr logic unless the logic module is manually reactivated and reloaded. In case of Pulsed GUI, Qudi doesn't crash but the GUI module won't launch and throw errors.

When does the bug occur?

It occurs when the GUI modules are launched, followed by deactivation of logic module and then relaunching the GUI.

How do we replicate the issue?

1. Launch Qudi
2. Launch Odmr GUI
3. Close the GUI and deactivate Odmr Logic
4. Activate Odmr GUI

Expected behavior

Unlike Odmr & Pulsed, other modules relaunch normally and don't crash under similar sequence of actions.

Relevant log output

2024-08-27 16:11:38 info qudi.Qudi Starting qudi in debug mode...
2024-08-27 16:11:38 debug qudi.core.threadmanager Creating thread: "remote-modules-server".
2024-08-27 16:11:38 debug qudi.core.threadmanager Creating thread: "local-namespace-server".
2024-08-27 16:11:38 info qudi.Qudi Applying configuration from "C:\qudi\qudi-iqo-modules\tests/test.cfg"...
2024-08-27 16:11:38 info qudi.Qudi Qudi configuration complete!
2024-08-27 16:11:38 info qudi.core.servers Starting RPyC server "local-namespace-server" on [localhost]:18861
2024-08-27 16:11:38 info qudi.core.servers Starting RPyC server "remote-modules-server" on [localhost]:12345
2024-08-27 16:11:38 info qudi.core.gui.gui Activating main GUI module...
2024-08-27 16:11:38 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-27 16:11:38 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-27 16:11:38 info qudi.core.gui.main_gui.main_gui.QudiMainGui IPython kernel for qudi main GUI successfully started.
2024-08-27 16:11:38 info qudi.Qudi Initialization complete! Starting Qt event loop...
2024-08-27 16:11:40 info qudi.core.services Client connected to local module service from [127.0.0.1]:62591
2024-08-27 16:11:43 info qudi.core.modulemanager Activating gui module "odmr.odmrgui.OdmrGui"
2024-08-27 16:11:43 info qudi.core.modulemanager Activating logic module "odmr_logic.OdmrLogic"
2024-08-27 16:11:43 info qudi.core.modulemanager Activating hardware module "dummy.microwave_dummy.MicrowaveDummy"
2024-08-27 16:11:43 info qudi.core.modulemanager Activating hardware module "dummy.finite_sampling_input_dummy.FiniteSamplingInputDummy"
2024-08-27 16:11:43 debug qudi.core.threadmanager Creating thread: "mod-logic-odmr_logic".
2024-08-27 16:11:48 info qudi.core.modulemanager Deactivating logic module "odmr_logic.OdmrLogic"
2024-08-27 16:11:48 info qudi.core.modulemanager Deactivating gui module "odmr.odmrgui.OdmrGui"
2024-08-27 16:11:48 debug qudi.core.threadmanager Quitting thread mod-logic-odmr_logic.
2024-08-27 16:11:48 debug qudi.core.threadmanager Waiting for thread mod-logic-odmr_logic to end.
2024-08-27 16:11:48 debug qudi.core.threadmanager Cleaning up thread mod-logic-odmr_logic.
2024-08-27 16:11:52 info qudi.core.modulemanager Activating gui module "odmr.odmrgui.OdmrGui"
2024-08-27 16:11:52 info qudi.core.modulemanager Activating logic module "odmr_logic.OdmrLogic"
2024-08-27 16:11:52 debug qudi.core.threadmanager Creating thread: "mod-logic-odmr_logic".
2024-08-27 16:11:52 warning Qt QObject::moveToThread: Current thread (0x1992f408900) is not the object's thread (0x1993631d8a0).
Cannot move to target thread (0x19940e0eef0)

Additional Comments

The issue has been observed on the current version of Qudi on Windows 10 with the dummy config.
I was able to trace the cause to line 176 in odmrgui.py . I think the issue occurs when setting up the connection between GUI signal and Logic slot. Using QueuedConnection might try to move the GUI object to the Logic module's thread. But, my speculation is that the GUI object is still in the previous logic module's thread and can't be moved from the current thread?

What seems to work for Odmr is reloading and reactivaing the logic module after deactivating it. If GUI is launched then, it launches normally. Pulsed GUI seems more complicated.

Contact Details

mohit.shah@uni-ulm.de

[takuya-ulm]

The same behavior was observed with the procedure described above.

The documentation on QueuedConnection:
https://doc.qt.io/qtforpython-5/PySide2/QtCore/Qt.html
says

The slot is invoked when control returns to the event loop of the receiver’s thread. The slot is executed in the receiver’s thread.

So, it is likely that the disconnections of the signals in the gui are not properly handeled, which messes up the thread management.

As @timoML suggested, I tried to call the disconnect functions before the logic is deactivated.
But I noticed that on_deactivate of gui is already called before on_deacivate of logic is called when deactivateing the logic.

At the same time, I noticed that activate of logic is called before activate of gui when activate_gui is called.
In fact, on_activate of logic is succeeding and the error is coming from activate of gui.
Now I can check the threads of logic and main by using thread().

QObject::moveToThread: Current thread (0x1c8e748cc90 =main thread = qudi.thread()) is not the object's thread (0x1c8ed7a6b80). Cannot move to target thread (0x1c880d1df00 =logic thread = odmr_logic.thread())

I guess this is called in activate of ManagedModule
https://github.com/Ulm-IQO/qudi-core/blob/main/src/qudi/core/modulemanager.py

           # Activate this module
            if self._instance.is_module_threaded:
                thread_name = self.module_thread_name
                thread_manager = self._qudi_main_ref().thread_manager
                thread = thread_manager.get_new_thread(thread_name)
                self._instance.moveToThread(thread)
                thread.start()

So far, I do not understand why it wants to move to the logic thread when activate of gui is called.

[takuya-ulm]

Now I tried the same procedure with different modules.
This happens in some of them, so the problem is coming from each module.

• Working

• scanner

• camera

• pid

• switch

• qdplot

• spectrometer

• Not working

• poi

• laser x

• pulsed x

• odmr x(crash)

I will have a look on the corresponding codes.

[NicolasStaudenmaier]

I looked into the ODMR modules. I couldn't find an immediately obvious error in the order of deactivation and activation. However, I have tried the description of @astropiuu and find somewhat weird behavior trying different things.

case 1:

1. Start Qudi & load ODMR GUI
2. deactivate ODMR GUI & deactivate ODMR logic
3. (optional; doesn't change result) activate ODMR logic
4. activate ODMR GUI
   --> Qudi crashes with the log output as reported above

case 2:

1. Start Qudi & load ODMR GUI
2. deactivate ODMR GUI
3. (optional; doesn't change result) deactivate & activate ODMR logic
4. reload ODMR logic (with the RELOAD button)
5. activate ODMR GUI
   --> GUI opens and works well

It seems strange to me that with the reload function of the logic everything works just fine, even if the logic was initially deactivated and activated as before. I don't have enough insight to understand the difference between the two. Is it possible that the reload function provides a full reset of the internal states and Qt bindings, that is not given with the deactivation/activation process? Maybe anyone with more knowledge of the Qudi core functions can comment?

If that is not the case, it is also possible that the problem is not related to Qudi but rather to Qt. In most other modules the re-activation works well. Maybe Qt fails with some garbage collection or dangling pointers causing the thread error as reported ...

[Neverhorst]

Currently deactivating and activating a module will not delete the module instance and recreate it but just call on_deactivate and on_activate as well as moving its thread affinity around (which somehow seems to fail, thus the warning from above).
Clicking reload will instead garbage collect the old instance and create a new one.
In the next major release of qudi-core the latter will be the standard behaviour for deactivate/activate instead and the reload will probably be removed.

From a quick glance I can not see what's wrong with the module. Might be a Qt bug but I'm not sure. Needs more time to investigate.