Skip to content

(Bug): (+POSSIBLE FIX) Natron Crashes when "interpretPythonScript()" returns False --> then throwing std::runtime_error from within a Q_SLOT makes Natron Crash #1046

@Emmett-Brown82

Description

@Emmett-Brown82

Make sure to follow our issue report guidelines

  • I'm using the latest version of Natron (not required but recommended)
  • I've restarted Natron and the issue persists
  • I've run Natron via the command line and the issue persists
  • I've followed the contributing guidelines to the best of my understanding
  • My issue is not on the issue tracker or in a pull request already (go search for it and dig around a little bit!)
  • This bug is reproducible

Natron version

Natron 2.5.0

Operating system

Linux, MacOS, Windows

System specs

RAM: 32 GB
CPU: AMD Ryzen 7
GPU: RTX 2050

Did you install Natron using the official installer?

  • Yes, I used the official installer
  • No, I installed from a binary archive
  • No, I compiled Natron from sources
  • No, I installed Natron via another method

Custom installation path

/opt/Natron-2.5.0

What were you trying to do?

I am a Senior Pipeline TD based in Madrid integrating Natron 2.5.0 into an opensource pipeline. I, therefore, code in Python 3. I am embedding a PyPanel in "pane2" using Natron's Python API. This PyPanel, at some point, is eventually reloaded without closing Natron. It deals with python modules with syntax errors.
After making one module raise an exception in python, i fix it again, and reload, then --> natron big CRASH.

What did you expect to happen? What happened instead?

I was expecting Natron to reload the fixed python modules without a CRASH.

In log i had the following QT message:

"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."

Which means that in the Natron C++ side, we, as developers, are not allowed to throw any exception at all from within a QT_SLOT method. And this is exactly what it is happening here (see Natron v2.5.0 branch and latest commit in C++ source code):

The origin as you can see is the Q_SLOT closePane()
Image

Then it calls removeTab()
Image

Then it calls removeTabToPython()
Image

Then in case the method "interpretPythonScript" return False it throws an std::runtime_error
Image

Which is not allowed by Qt4/Qt5: this is forbidden because of the way Qt works, you cannot propagate exceptions from a Q_SLOT method. So, basically i see two possible options:

  • (1) either we prevent the std::runtime_error at that line to be thrown (for example, by commenting it out)
  • (2) either we place a Try-Catch inside every single Q_SLOT with the according code inside.

I managed to compile a Python 3.10/PySide/Qt4 Natron v2.5.x Version in Ubuntu 18.04 and it has been tested that whenever I reload dynamically the python modules it DOES NOT CRASH ANYMORE. My option to go was editing the code and placing a Try-Catch clause.

Step-by-step reproduction instructions

Start Natron
Embed a Python PyPanel
Load modules dynamically
Provoke a syntax error in one of the modules loaded dynamically
Fix back the module.
Reload dynamically the whole Qt Widget.
--> notice the crash.

Additional details

This bug is tricky to catch since it is related to people coding in python using the API.
i am not allowed to provide the full code because of IP reasons.

To sum up, as a good practice, try not to throw exceptions from within Q_SLOT methods, since this makes crash Natron because of the way Qt works. Furthermore, since it is a C++ exception, we are due to TryCatch it in C++ side, we cannot override the QApplication.notify method from the PySide side. This does not work.

I ll provide more clarification if it is not enough. But this bug is meant to happen in all Natron releases.

I ll be happy to keep discussing it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    type:bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions