AttributeError: 'NoneType' object has no attribute 'signal_triggered' on teardown

[The-Compiler]

I have some code which looks like this:

class TestJavascriptEscape:

    def _test_escape(self, text, qtbot, webframe):
        # ...
        with qtbot.waitSignal(webframe.loadFinished, raising=True):
            webframe.setHtml(html_source)
        # ...

    @pytest.mark.parametrize('text', TESTS)
    def test_real_escape(self, webframe, qtbot, text):
        """Test javascript escaping with a real QWebPage."""
        self._test_escape(text, qtbot, webframe)

    @hypothesis.given(hypothesis.strategies.text())
    def test_real_escape_hypothesis(self, webframe, qtbot, text):
        """Test javascript escaping with a real QWebPage and hypothesis."""
        self._test_escape(text, qtbot, webframe)

With these fixtures:

@pytest.fixture(scope='session')
def qnam():
    """Session-wide QNetworkAccessManager."""
    from PyQt5.QtNetwork import QNetworkAccessManager
    nam = QNetworkAccessManager()
    nam.setNetworkAccessible(QNetworkAccessManager.NotAccessible)
    return nam


@pytest.fixture
def webpage(qnam):
    """Get a new QWebPage object."""
    from PyQt5.QtWebKitWidgets import QWebPage

    page = QWebPage()
    page.networkAccessManager().deleteLater()
    page.setNetworkAccessManager(qnam)
    return page


@pytest.fixture
def webframe(webpage):
    """Convenience fixture to get a mainFrame of a QWebPage."""
    return webpage.mainFrame()

When I run this (after adding the qtbot.waitSignal call) on Ubuntu Trusty (and only there!) with PyQt 5.2.1, I get this giant log. The gist of it is this:

==================================== ERRORS ====================================
____ ERROR at teardown of TestJavascriptEscape.test_real_escape_hypothesis _____

self = <_pytest.runner.SetupState object at 0x7f991bf86898>
colitem = <Function 'test_real_escape_hypothesis'>

    def _callfinalizers(self, colitem):
        # [...]

.tox/unittests/lib/python3.4/site-packages/_pytest/runner.py:356: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
.tox/unittests/lib/python3.4/site-packages/_pytest/python.py:1868: in finish
    func()
.tox/unittests/lib/python3.4/site-packages/_pytest/python.py:1826: in teardown
    next()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

qapp = <PyQt5.QtWidgets.QApplication object at 0x7f9913d87af8>
request = <SubRequest 'qtbot' for <Function 'test_real_escape_hypothesis'>>

    @pytest.yield_fixture
    def qtbot(qapp, request):
# [...]
E               Failed: Qt exceptions in virtual methods:
E               ________________________________________________________________________________
E                 File "/home/buildbotx/slaves/slave/ubuntu-trusty/build/.tox/unittests/lib/python3.4/site-packages/pytestqt/plugin.py", line 427, in _quit_loop_by_signal
E                   self.signal_triggered = True
E               
E               AttributeError: 'NoneType' object has no attribute 'signal_triggered'
E               ________________________________________________________________________________
E                 File "/home/buildbotx/slaves/slave/ubuntu-trusty/build/.tox/unittests/lib/python3.4/site-packages/pytestqt/plugin.py", line 427, in _quit_loop_by_signal
E                   self.signal_triggered = True
E               
E               AttributeError: 'NoneType' object has no attribute 'signal_triggered'

[repeated... a lot]

Do you have any idea what's happening there 😟? It seems self is None... I've seen this in QObjects which are already deleteLater()'ed, but SignalBlocker isn't one...

I'll try to produce a minimal example later.

[nicoddemus]

Hmmm, that's really strange... 😟 it seems the internal callback mechanism used by signals/slots in PyQt keeps a reference to the unbound method and a weak reference to instance (self), and doesn't actually notices that the instance died and calls the unbound method with None anyway...

If you could reproduce that in a minimum example it would be great, to at least we can try to workaround it and have a regression test for the problem...

[The-Compiler]

Yeah, I guess something like that's happening... but why is that code run during teardown (i.e. qapp.processEvents() at all? The signal gets emitted and the code gets executed, after that the additional QEventLoop quits - so why is that function even called again?

[nicoddemus]

That's an excellent question... no idea how to create a minimal example which exhibits the same behavior thought... 😟

[The-Compiler]

At least I can reliably reproduce it, so it (hopefully) shouldn't be too hard to minimize it. I hope I'll have time to attempt that today.

[The-Compiler]

It seems it's somehow related on how hypothesis interacts with fixtures.

I can reproduce it with this example:

import pytest
import hypothesis
import hypothesis.strategies

from PyQt5.QtCore import QTimer

@pytest.fixture()
def timer():
    t = QTimer()
    t.setInterval(0)
    t.setSingleShot(True)
    return t


@hypothesis.given(hypothesis.strategies.booleans())
def test_foo(qtbot, timer, b):
    with qtbot.waitSignal(timer.timeout):
        timer.start()

• When setting up the QTimer directly in test_foo instead of a fixture, it doesn't happen.
• When making hypothesis only feed the test with one value, it doesn't happen.
• When hypothesis calls the test n times, I get the error n - 1 times - this is why my log got spammed earlier, as I used strategies.text() which hit the maximum of 200 examples.

@DRMacIver, any idea what's going on?

I'll try to understand how hypothesis.given works and if I can construct an example which doesn't use hypothesis.

[jerith]

The problem is that the fixture object is constructed once and used multiple times. Here's an example with just pytest and hypothesis:

import pytest
import hypothesis
import hypothesis.strategies


class State(object):
    def __init__(self, value):
    self.value = value


@pytest.fixture()
def state():
    return State(0)


@hypothesis.given(hypothesis.strategies.integers())
def test_foo(state, num):
    if num > 0:
        state.value += 1
    assert state.value < 2

[DRMacIver]

What should simply be happening here is that as @jerith says you're reusing the mutable timer value in the test (Hypothesis can't re-execute fixtures with each example. I need to signpost this problem better). This should be equivalent to the following test:

def test_foo(qtbot, timer):
   for b in [False, True]:
        with qtbot.waitSignal(timer.timeout):
            timer.start()

[The-Compiler]

It seems it's simply triggered by waiting for the signal twice:

import pytest

from PyQt5.QtCore import QTimer


def test_foo(qtbot):
    timer = QTimer()
    timer.setInterval(0)
    timer.setSingleShot(True)
    with qtbot.waitSignal(timer.timeout):
        timer.start()
    with qtbot.waitSignal(timer.timeout):
        timer.start()

Why it doesn't happen with Qt 5.3+ is probably explained by this documentation page:

Execution of Python Slots

In previous versions, when a signal was emitted to a Python slot that was not decorated with pyqtSlot(), it would not check that the underlying C++ receiver instance still existed. This matched the PyQt4 behaviour at the time that PyQt5 v5.0 was released, but doesn’t reflect the standard C++ behaviour.

The lack of a check meant that an object could connect its destroyed() signal to itself so that it could monitor when its underlying C++ instance was destroyed. Unfortunately this turned out to be a potential source of obscure bugs for more common code.

In this version the check has been introduced - hence creating an incompatibility for any code that relies on the earlier behaviour. As a workaround for this the no_receiver_check argument has been added to connect() which allows the check to be suppressed on a per connection basis.

(however, even when I change the connection in SignalBlocker.connect to use no_receiver_check, I can't reproduce this on newer PyQt-versions)

[The-Compiler]

I'm working on a fix.

[ctismer]

Very interesting for me.
I'm struggling to understand how signals should be implemented for PySide2.
So if there is something I need to be aware of, the time is perfect to influence me ;-)

[The-Compiler]

PR: #71 - thanks everyone for your help tracking this down!

@ctismer I think the lesson to learn from this is to disconnect all signals when a Python wrapper is destroyed (if I understand the underlying PyQt issue correctly).