Crashes always occurring while performing simple operations on high-order VTU files

ParaView Support
1

Hello everyone, I’m new to ParaView.

I frequently encounter crashes while using ParaView, which is frustrating because I haven’t saved my previous operations. When I reopen my VTU file and try to post-process it, I often experience repeated crashes, and I receive no error messages, which is baffling.

Allow me to provide more details. I’m using Windows 11 and ParaView version 5.11.1. My VTU files are computed using the open-source program PyFR, and they are over 100MB in size, using a second-order VTU format. For now, I’ve set ParaView’s Nonlinear Subdivision level to 1.

The crashes often occur during relatively simple post-processing operations. For example, after opening the VTU file, I calculate the Q criterion using the Gradient filter and then use Contour to extract an iso-surface of the Q criterion. These crashes happen without any additional complex steps.

I’ve disabled “Apply changes to parameters automatically,” and my computer has 64GB of memory. I’ve also used the Memory Inspector to ensure there are no memory issues.

In the past, I tried using ParaView to handle high-order VTU files exported from PyFR computations, but the frequent crashes without any error messages made me consider giving up on ParaView. By the way, when I was processing high-order VTU files on Ubuntu, the crashes I encountered often resulted in a message in the terminal saying “Segmentation fault (core dumped),” similarly without any valuable information.

I’d greatly appreciate any help. If more details are needed, please feel free to ask. I want to understand why these crashes might be happening. Is there a way to monitor the sudden crashes and determine their causes? Or could you provide more guidance on working with high-order VTU files? Thank you very much!

2

To add further, crashes don’t always occur even when performing the same operations. They seem to happen with a certain level of probability, which is also perplexing to me. Any advice would be greatly appreciated.

3

This is usually a Linux output. Are you in WSL of some kind?

4

I’m sorry I didn’t make things clear.
In fact, what I want to express is that I have conducted similar tests on windows and original ubuntu (not WSL) respectively. The test result of windows is flashback without any hint, and the test result of ubuntu is segmentation fault (core dumb). In short, I have not got any useful error information, so I feel very distressed.

If you need any more information, I’m willing to provide it. I’m sorry again for not being able to express it clearly.
Best regards.

5

If you get a segfault on Linux, you can run ParaView under gdb:

$ gdb --args path/to/paraview --any --args --for --paraview
# run paraview
(gdb) r
# ~~~ reproduce the error

# get a backtrace
(gdb) bt
<provide this output>

FWIW, this works for just about everything on Linux. Symbols may be missing, but sometimes this is sufficient (otherwise we’ll need to get a build with debug symbols).