# vtk Debug Leak mitigation with Catalyst

**URL:** https://discourse.paraview.org/t/vtk-debug-leak-mitigation-with-catalyst/3183
**Category:** In Situ Support
**Tags:** vtk
**Created:** [December 13, 2019, 1:36pm UTC](https://discourse.paraview.org/t/vtk-debug-leak-mitigation-with-catalyst/3183 "2019-12-13T13:36:09Z")
**Posts on this page:** 1
**Showing post:** 8

<div class="post-metadata">

### Author: ![cory.quammen](https://discourse.paraview.org/user_avatar/discourse.paraview.org/cory.quammen/32/11193_2.png) [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [January 3, 2020, 2:53pm UTC](https://discourse.paraview.org/t/vtk-debug-leak-mitigation-with-catalyst/3183/8 "2020-01-03T14:53:23Z")

</div>

Okay, thanks for clarifying your non-use of `mpi4py`. That means the finger is pointed at ParaView itself.

Looking at the `coprocessing` python module, as best I can tell your backtrace involves the call [here](https://gitlab.kitware.com/paraview/paraview/blob/master/Wrapping/Python/paraview/coprocessing.py#L344). Now, the question is, where are the other MPI processes stuck? If it is possible to get a stack trace on one of those processes, then we can see where things go awry. I know that isn’t the easiest or quickest thing to do, but without that, finding the communications mismatch is a bit like a needle in a haystack.

---

_[View the full topic](https://discourse.paraview.org/t/vtk-debug-leak-mitigation-with-catalyst/3183)._