Compilation testers needed

[openBrain]

No, I didn't know that an environment variable has to be set now. I will try it. Thanks!

Could we enable by default when a debug build is done ?

[wmayer]

No, I didn't know that an environment variable has to be set now. I will try it. Thanks!

Could we enable by default when a debug build is done ?

Sure. I have to read some Qt docs about the logging, first.

[chennes]

@chennes If it may help, below the callstack of the main thread when this message appears :
[...]
It looks like a QTimer timeout will trigger some fake click on a RejectRole button on some dialog.
IIRC, this is mechanism used somewhere in your Gui tests. Maybe there are several dialogs open and at some moment the wrong one is targeted.

Thanks for that stack trace. Yes, the mechanism that closes those windows is attached to a QTimer, and works as follows:

1. Ask for the current active modal dialog
2. Check its window title
3. If the title is the one we are looking for, look for the button being tested
4. If the button is found, click it (this may be an accept or a reject, depending on the test)
5. If the button is not found, send the dialog the reject signal directly (test fails)
6. If the window title of the current modal dialog title does not match, get a list of all windows
7. Loop over the list of all windows and check their titles
8. If any of them match, tell it to reject (test fails)
9. If we didn't find any window with the correct title, repeat the timer

From that backtrace it looks like it's in the primary successful path: it found a matching dialog and is trying to click() a button. I wonder if maybe the dialog is not fully constructed or something like that. Can you change the timeout value to something absurdly large, like 5000ms, in src/Mod/AddonManager/AddonManagerTest/gui/gui_mocks.py line 50? Maybe I just need to give the dialog more time to get itself situated (obviously 5000ms isn't going to be a final value, instead I'll try to figure out if there is some kind of thing I can check to see if the init is complete before hitting the button).

[openBrain]

From that backtrace it looks like it's in the primary successful path: it found a matching dialog and is trying to click() a button. I wonder if maybe the dialog is not fully constructed or something like that. Can you change the timeout value to something absurdly large, like 5000ms, in src/Mod/AddonManager/AddonManagerTest/gui/gui_mocks.py line 50? Maybe I just need to give the dialog more time to get itself situated (obviously 5000ms isn't going to be a final value, instead I'll try to figure out if there is some kind of thing I can check to see if the init is complete before hitting the button).

I did with 2000ms.
This isn't really better but maybe gave an interesting trace (at least now we have a failing test and a traceback) :

Code: Select all

16:23:56  The following Python packages are allowed to be automatically installed:
16:23:56    * numpy
16:23:56    * openexr
16:23:56    * gmsh-dev
16:23:56    * docutils
16:23:56    * blinker
16:23:56    * autobahn
16:23:56    * awkward
16:23:56    * nine
16:23:56    * xlutils
16:23:56    * ezdxf
16:23:56    * aiofiles
16:23:56    * comtypes
16:23:56    * pygit2
16:23:56    * ply
16:23:56    * pyoptools
16:23:56    * lxml
16:23:56    * pillow
16:23:56    * pydocx
16:23:56    * openpyxl
16:23:56    * xlwt
16:23:56    * msgpack
16:23:56    * capytaine
16:23:56    * trimesh
16:23:56    * nodeeditor
16:23:56    * matplotlib
16:23:56    * etabs_api
16:23:56    * qtrangeslider
16:23:56    * scipy
16:23:56    * geomdl
16:23:56    * hausdorff
16:23:56    * numba
16:23:56    * xlrd
16:23:56    * beautifulsoup4
16:23:56    * pynastran
16:23:56    * qtpy
16:23:56    * olefile
16:23:56    * pandas
16:23:56    * ifcopenshell
16:23:56    * py-slvs
16:23:56    * scikit-image
16:23:56    * ocp
16:23:56    * requests
16:23:56    * rhino3dm
16:23:56    * pyyaml
16:23:56    * gmsh
16:23:56    * markdown
16:23:56    * pycollada
16:24:27  FAILED: test_timer_launches_progress_dialog (AddonManagerTest.gui.test_uninstaller_gui.TestUninstallerGUI)
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/case.py", line 59, in testPartExecutor
    yield
  File "/usr/lib/python3.10/unittest/case.py", line 591, in run
    self._callTestMethod(testMethod)
  File "/usr/lib/python3.10/unittest/case.py", line 549, in _callTestMethod
    method()
  File "/home/ob/dev/FCBuild/Mod/AddonManager/AddonManagerTest/gui/test_uninstaller_gui.py", line 118, in test_timer_launches_progress_dialog
    self.assertTrue(
AssertionError: False is not true : Failed to find the expected dialog box

16:24:27  Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

Addon added: 3D_Printing_Tools
16:24:28  Addon added: 3DfindIT
16:24:28  Addon added: A2plus
16:24:28  Addon added: AirPlaneDesign
16:24:28  Addon added: Alternate_OpenSCAD
16:24:28  Addon added: animation
16:24:28  Addon added: AnimationFreeCAD
16:24:28  Addon added: ArchTextures
16:24:28  Addon added: assembly2
16:24:28  Addon added: Assembly3
16:24:28  Addon added: Assembly4
16:24:28  Addon added: Autoload
16:24:28  Addon added: BCFPlugin

Still it freezes on the "Updating addons" dialog as described in the GH issue.
I notice that while setting a 2000ms setting in the timer slows down the whole process, the sequential tasks done when this "Updating addons" dialog is displayed (and the previous one, can't catch its name) still go very fast ; maybe too fast.

[wmayer]

Do you have enabled the respective warning category?

No, I didn't know that an environment variable has to be set now. I will try it. Thanks!

Setting this environment variable doesn't fix the problem. The issue must be caused by installing our custom message handler. Before doing so the messages are printed to the console window and afterwards all messages are swallowed.

For testing purposes I have changed Application::initApplication() to:

Code: Select all

void Application::initApplication()
{
    static bool init = false;
    if (init) {
        Base::Console().Error("Tried to run Gui::Application::initApplication() twice!\n");
        return;
    }

    {
        QObject* obj = new QObject();
        // The warning is shown in the console
        QObject::connect(obj, SIGNAL(testSignal()), obj, SLOT(testSlot())); 
    }
    try {
        initTypes();
        new Base::ScriptProducer( "FreeCADGuiInit", FreeCADGuiInit );
        init_resources();
        old_qtmsg_handler = qInstallMessageHandler(messageHandler);  // Install the message handler
        init = true;
    }
    catch (...) {
        // force to flush the log
        App::Application::destructObserver();
        throw;
    }
    {
        QObject* obj = new QObject();
        // The warning is not shown in the console. But it is shown when commenting out line old_qtmsg_handler = qInstallMessageHandler...
        QObject::connect(obj, SIGNAL(testSignal()), obj, SLOT(testSlot())); 
    }
}

[chennes]

Yes, you're right: -- the failing test is failing because before the two seconds is up, the dialog has been killed. So to actually have the 2 second timer be useful, we also have to slow down the test itself. test_uninstaller_gui.py line 110 has a timer that is killing the dialog after one second, can you also increase that, to something larger than 2 seconds?

[wmayer]

Setting this environment variable doesn't fix the problem.

Found the problem. I have forgotten to set CMAKE_BUILD_TYPE to debug for my Qt6 build. Because in release mode all Qt warnings are only handled as log messages they weren't reported to the console or output window.

Since the default message handler of Qt also prints in release mode I have changed our custom handler to also print warnings and errors in release mode.
git commit 079bdc64b1

[chennes]

maybe too fast.

Just a quick heads-up that I've isolated the problem: on Linux, you really, really can't use terminate() on a thread, even if that's the only way to actually stop it (e.g. a long-running git process). So I'm doing some refactoring around those calls, and should have a solution pushed later today. Sorry it's taken me so long to debug! I hope you've been able to make progress on the CI despite it.

[openBrain]

Just a quick heads-up that I've isolated the problem: on Linux, you really, really can't use terminate() on a thread, even if that's the only way to actually stop it (e.g. a long-running git process). So I'm doing some refactoring around those calls, and should have a solution pushed later today. Sorry it's taken me so long to debug! I hope you've been able to make progress on the CI despite it.

Great you got it.
On my side was OK to move forward on the CI. I'm just polishing it before submitting the PR.
Just this problem was ignored by current CI, and this could have made it difficult to introduce new one if all pushes and PRs were suddenly failing CI because of that.
And honestly Addon Manager isn't alone. There is another blocking issue with Path (PathAdaptative to be more precise). If someone want to tackle this, I'd be happy to give more info.

[chennes]

Great you got it.

OK, I believe git commit d6b3efc7a actually resolves this, so please let me know if it does not.