@markomarkovic What are the steps to reproduce this error? I am not seeing it, even in CI.

Fair — it doesn't fail the suite as it stands, and that's really the point: the connection is dangling, but nothing currently exercises it. Two things hide it:

1. PyQt routes an exception raised inside a slot to sys.excepthook instead of propagating it, so it surfaces as a stderr traceback rather than a failure.
2. Nothing in the current tests destroys a LogViewer while PRINT_REDIRECTOR is still emitting.

Deterministic repro on master (6daf9c0) — fails there, passes with this PR:

import sys
from PyQt5 import sip
from PyQt5.QtWidgets import QMessageBox
from cq_editor.__main__ import MainWindow
from cq_editor.main_window import PRINT_REDIRECTOR


def test_stray_output_after_log_destroyed(qtbot, mocker):
    mocker.patch.object(QMessageBox, "question", return_value=QMessageBox.Yes)
    mocker.patch.object(QMessageBox, "warning", return_value=QMessageBox.Discard)

    win = MainWindow()
    qtbot.addWidget(win)
    sip.delete(win.components["log"])   # the window's LogViewer goes away

    errors = []
    original, sys.excepthook = sys.excepthook, lambda t, e, tb: errors.append(t.__name__)
    try:
        PRINT_REDIRECTOR.sigStdoutWrite.emit("stray output")
    finally:
        sys.excepthook = original

    assert errors == []   # master: ['RuntimeError'] - LogViewer has been deleted

Mechanism: PRINT_REDIRECTOR is a module-level singleton that outlives any window. PyQt drops a connection to a QObject's bound method when that QObject is destroyed, but a lambda connection has no receiver to track, so it survives and calls into freed C++.

Where it stops being theoretical: adding pytest-qt tests that build MainWindows. While writing tests for another feature, the full suite hit this repeatedly (once per previously-destroyed LogViewer) and pytest-qt escalated it into a SETUP ERROR on the following test. That's what prompted this fix.

@markomarkovic What was the reason for creating a new test file for main window tests instead of integrating this into the existing test_app.py tests file?

No real reason beside grouping. It's a lifetime regression test for the main_window.py singleton rather than app behavior test but there's nothing really stopping us from moving it into test_app.py if that's preferred.