<div dir="ltr"><div dir="ltr"><div>Hi Jeremy,</div><div>thanks for the quick reply !<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 22, 2023 at 1:16 PM Jeremy Katz <<a href="mailto:jkatz@volexity.com">jkatz@volexity.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 9/22/23 09:35, Stefan Seefeld wrote:<br>
<br>
> 1. run the above command, but click the "quit" button immediately. Thus <br>
> results in the error message `QObject::killTimer: Timers cannot be <br>
> stopped from another thread`,<br>
> followed by a segmentation fault<br>
<br>
My guess is that the QApplication object is being destroyed by the <br>
garbage collector, which isn't running in the QApplication's thread. <br>
Adding an explicit `del <a href="http://self.app" rel="noreferrer" target="_blank">self.app</a>` after the QApplication.exec returns <br>
prevents the crash for me.<br></blockquote><div><br></div><div><br></div><div>Indeed, that works. (Unfortunately this approach is likely not to work in general, as pytest appears to be holding on to references in different places, making it highly unlikely that I can get the application's refcount down to 0 at a specific time / location in the code.</div><div><br></div><div>Note that this is really just a test prototype I'm writing to understand the underlying issues a little better. The real test logic will use a QApplication that's exposed to Python using something other than sip (boost.python), and I'm considering ways to deliberately circumventing the reference counting, precisely so I can get back the control to delete the underlying Qt objects whenever I need to, rather than when the Python runtime would normally do it.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
This strategy likely won't work (AFAIK...) on macOS. While Qt is <br>
relatively happy to run in any thread, the mac UI interface must be used <br>
from the initial thread.<br>
<br>
> 2. rather than just "yielding" to the test function, yield the <br>
> application object (so the test function can interact with it). No <br>
> matter when you click the "quit" button, the result is the same as in 1.<br>
> <br>
> 3. call `h.app.quit()` after he `yield` (i.e. as soon as the test <br>
> function completes). Result: the application becomes unresponsive, but <br>
> doesn't stop<br>
<br>
2 and possibly 3 sound like more instances of a wrong thread situation.<br>
</blockquote></div><br clear="all"><div>The call to `quit()` is documented to be thread-safe, so it should work fine even when made programmatically from other threads than the one running the event loop.</div><div>Is this potentially an issue with PyQt not routing the signal correctly ?<br></div><div><br></div><div>Thanks,<br></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><img src="https://ci3.googleusercontent.com/mail-sig/AIorK4yh4RzsqlxV6irScDGRVZ8a7NRCh_INtpPsAHx2Y8v4Vu3VKsI54RFNs3YRZk_2xTTtMMdSCzdNrf5XRUlmF4BkezmtZv-j5c3A4G0hEA"></div><div><pre>      ...ich hab' noch einen Koffer in Berlin...
</pre></div></div></div></div>