Crash at closing when embeded in some Qt application as child widget

[pyvista]

Crash at closing when embeded in some Qt application as child widget

[GuillaumeFavelier]

Hi and thanks for reporting your issue. It's definitely a strange one and since it is really related to memory, I'll take this chance to say that #66 really helps to track VTK objects remaining in memory 👍

This is the first time I see this error and after diving into C++ code, I can only assume it happens because Delete() is called twice? Sadly, this is all theory and I can't confirm it but this is the only thing I could see going wrong in SetInstance(). Sorry for not being of much help.

Reference: https://gitlab.kitware.com/vtk/vtk/-/blob/master/Common/Core/vtkOutputWindow.cxx#L177-189

[dephora]

Oh bummer, will give vedo a go, anticipating similar results then likely do the same as you.

Appreciate the quick response and tip!

[dephora]

vedo works without issue leading me to believe it's not a vtk issue. Will try to track down why it works and why pyvista is crashing.

Let me rephrase that, obviously it's not a vtk issue at the root as importing vtk alone works... but rather a vtk issue in the context of vedo / pyvista.

[T4mmi]

Thanks for the insight !
If multiple call to Delete() is an issue I'll look into it since it's highly probable that I wrongly managed deletions...
Will close if it sloves :)

[T4mmi]

After some try/die investigations ... it seems to be linked with the interaction between pyvista/vtk and QGIS ! ...

how to reproduce (inside QGIS Python console):

import subprocess
from qgis.PyQt.QtCore import QStandardPaths

interpreter = QStandardPaths.findExecutable("python")
command = (
    f"{interpreter} -m pip install pyvista --user"  # --user so it works even without admin rights (default windows install)
)
# run qgis-python pip
subprocess.check_call(command, shell=True)

import pyvista as pv

then quit QGIS, it should crash ...

[T4mmi]

should add that import vtk works fine

[dephora]

@T4mmi - Running into this issue in QGIS as well, any luck?

[T4mmi]

Actually we didn't ... 😞
So we got rid of pyvista layer and manage to directly wrap a vtkRenderer inside QGIS ...

[Huite]

Just to leave some potentially helpful ideas: rather than skipping pyvista entirely, it's not too difficult to communicate between two Python interpreters: just use a socketserver and communicate. This requires starting a separate Python interpreter, but this is not too difficult to manage (once you've figured out all the subtleties with environmental variables, and how (not) to inherit them).

On the QGIS side:
https://gitlab.com/deltares/imod/qgis-tim/-/blob/master/plugin/qgistim/server_handler.py

On the external interpreter side:
https://gitlab.com/deltares/imod/qgis-tim/-/blob/master/gistim/tim_server.py

Basic idea: you start the interpreter, then the buttons in QGIS just send commands.
This is not great on one side: you can't easily share data in memory. On the other side, fetching data via QGIS and getting it into numpy array form is often inconvenient or slow (non-vectorized). So you have to duplicate the data anyway...

For small bits of data, just serialize everything into json and send that.

The upside is that you can go as crazy as you want with dependencies, as you can rely on a conda/mamba environment with complex binaries, rather than the somewhat dependency-handicapped QGIS Python interpreter.

[T4mmi]

Hi,
thanks for the feedback ... but in our end, the point is to bring (a rather small part of) paraview functionnalities to QGIS for end users that are somehow 'allergic' to cmd lines 😉
Anyway with the efforts of vtk to wrap everything in python we really feel that pyvista is no longer a good adding since it brings too much complexity in code maintaing.

BUT we still use it for 'power users' coupled with advanced (...) jupyter notebooks.
And BTW thanks @dephora for introducing vedo, i didn't knew it ... is there any link with pyvista ?

[dephora]

@T4mmi As for the vedo link with pyvista - not that I know of. Funny you mention Paraview as we plan on using it and others which is one of the reasons I'd rather stay with pyvista as it's created / maintained by Kitware employees (or at least one).