# Volume rendering broken in latest Linux previews?

**URL:** <https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974>\
**Category:** Support\
**Created:** [May 8, 2026, 6:49pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974 "2026-05-08T18:49:10Z")\
**Posts on this page:** 13\
**Page:** 2

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [May 12, 2026, 12:57pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/21 "2026-05-12T12:57:00Z")

</div>

My Claude found this which seems relevant: [Cannot import gmsh Python package](https://discourse.slicer.org/t/cannot-import-gmsh-python-package/29344)

It also came up with all these suggestions.

> 🤖 The rest of this post is AI-generated content.

## Concrete debugging plan (what I’d ask Murat to run)

1. **Capture a real backtrace, not just frame 0:**

```auto
ulimit -c unlimited
./Slicer # reproduce crash
coredumpctl gdb # or: gdb ./bin/SlicerApp-real core
(gdb) bt full
(gdb) info sharedlibrary
(gdb) info proc mappings

```

Frame 0 alone tells us nothing about the caller; `bt full` will show which Slicer/VTK code fed garbage into the regex.  
2. **Identify which libstdc++ is actually loaded at the crash site:**

```auto
cd Slicer-5.11.0-2026-05-05-linux-amd64
LD_DEBUG=libs ./Slicer 2>&1 | grep -E 'libstdc\+\+|libgcc_s' | head
ldd bin/SlicerApp-real | grep -E 'stdc\+\+|gcc_s'
strings -a $(ldd bin/SlicerApp-real | awk '/libstdc\+\+/{print $3}') \
  | grep -E '^GLIBCXX_[0-9]' | sort -V | tail
strings -a /usr/lib/x86_64-linux-gnu/libstdc++.so.6 \
  | grep -E '^GLIBCXX_[0-9]' | sort -V | tail

```

If those two GLIBCXX max versions differ, that’s the smoking gun.  
3. **Run with a clean environment to rule out conda contamination:**

```auto
env -i HOME=$HOME PATH=/usr/bin:/bin DISPLAY=$DISPLAY \
    LANG=C.UTF-8 LC_ALL=C.UTF-8 \
    ./Slicer

```

If that fixes it, walk `printenv | grep -E 'LD_|PYTHON|CONDA'` to find the offending var.  
4. **Check the locale path** (cheap and worth ruling out):

```auto
locale ; locale -a | grep -i utf

```

1. **Bisect the factory builds.** [download.slicer.org](http://download.slicer.org) keeps weekly Linux previews; install three or four (e.g. 2026-04-01, 2026-04-15, 2026-04-28, 2026-05-05) and find the first that crashes on Murat’s box. Then `git log --oneline <good_rev>..<bad_rev>` on Slicer + look at Superbuild revisions of VTK/Qt for that span. (The thread does _not_ yet identify a regressing commit, despite what the WebFetch summary claimed.)
2. **If frame 0’s `bt full` shows the regex string is empty / null / garbage** , the bug is most likely on the _Slicer_ side (a recent change that passes an uninitialized `std::string` to `std::regex`), not glibc. Same fix shape as the 2022 `vtkSlicerVolumeRenderingLogic::CreateROINode` regression in 2022-01-10.

## Fix paths

- **If libstdc++ mismatch is confirmed** (step 2): ship a vendored `libstdc++.so.6` in `Slicer-5.11/lib/` and add it to the launcher’s `LD_LIBRARY_PATH` ahead of system. Slicer used to do this; if it was dropped, that’s the regression. Cheapest verification: `cp /usr/lib/.../libstdc++.so.6 lib/Slicer-5.11/` on the build machine, re‑run, see if the crash goes away.
- **If it’s a conda/Anaconda env pollution:** add a launcher guard that scrubs `LD_LIBRARY_PATH` entries containing `anaconda`/`miniconda`/`conda` before exec, and document it.
- **If it’s a real null‑string fed into `std::regex`:** fix the call site (`bt full` will name it). No glibc involvement.
- **For chir.set’s Wayland/GLX issue** (separate): have Slicer’s launcher detect `XDG_SESSION_TYPE=wayland` + Qt5 and default `QT_QPA_PLATFORM=xcb`, since Slicer’s Qt5 has no working Wayland path with the VTK GL contexts.

Want me to draft the launcher patch for the Wayland default, or to scaffold a `slicer-debug-libs.sh` script that runs steps 1–4 in one go?

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [May 12, 2026, 3:00pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/22 "2026-05-12T15:00:08Z")

</div>

I don’t really know what to do with this.

1. It is already clear in my case that the breaking change is around vtk9.5.1-\>9.6.0 commit in March. After that, slicer crashes. (this specifically: [ENH: Add support for building against VTK version 9.6.0 · Slicer/Slicer@1b21266 · GitHub](https://github.com/Slicer/Slicer/commit/1b21266bf47f126ece58d12b87160e38f55ad258))
2. I do not use conda or inject LD\_LIBRARY\_PATH.

The rest I have no clue.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [May 12, 2026, 5:26pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/23 "2026-05-12T17:26:19Z")

</div>

Okay, after our discussion at the developer meeting @lassoan suggested that a workaround would be to disable surface smoothing in the volume renderer:

![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/c/d/cd8ef966205927ad1342234893b8a4368afec9f2.png)

I tested and I can get the crash with the current preview build if it turn on this feature, so it does seem to be the thing that triggers the bad code path. @muratmaga can you confirm?

We also realized that the builds with the crash are actually using the new VTK version, so this is probably what triggered the underlying issue. I’ll try some of the things Claude suggested and see if I can get any more info on any underlying glibc issues.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [May 12, 2026, 9:02pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/24 "2026-05-12T21:02:37Z")

</div>

> 🤖 This post was written with AI assistance.

So after some testing it looks like there’s a C++ issue that I won’t try to explain that happens on linux and has to do with the way VTK compiles by default.

Probably we can patch it with these flags when building VTK:

```auto
  ...
  CMAKE_CACHE_ARGS
    ...
    -DCMAKE_CXX_VISIBILITY_PRESET:STRING=hidden
    -DCMAKE_VISIBILITY_INLINES_HIDDEN:BOOL=ON
    -DCMAKE_SHARED_LINKER_FLAGS:STRING=-Wl,-Bsymbolic-functions
)

```

It would be better for VTK to be built like this by default, but we can do this as a workaround if we want.

For the very short run, just turning off the surface smoothing in volume rendering is a patch.

The underlying issue is illustrated by just running this script. Maybe we can refine this here and then file an issue in the VTK gitlab with the suggested fix.

```auto
exouser@sdp-test-volume-render:~/Downloads$ cat ~/repo.sh 
#!/usr/bin/env bash
# Reproducer: VTK 9.6 std::regex ODR exposure on Linux/ELF.
# Paste into any Linux box with g++, python3-venv, and an older g++ available.
set -euo pipefail

OLDGCC=${OLDGCC:-g++-9} # override if g++-9 missing; try g++-11 or g++-13
if ! command -v "$OLDGCC" >/dev/null; then
  cat >&2 <<EOF
need $OLDGCC in PATH.
  Ubuntu/Debian: sudo apt-get update && sudo apt-get install -y $OLDGCC
                 (older series may need 'universe' enabled, or try OLDGCC=g++-11)
  Fedora/RHEL: sudo dnf install -y gcc-toolset-11-gcc-c++
                 then: scl enable gcc-toolset-11 -- bash (and re-run this script)
  Arch: sudo pacman -S gcc11 (then OLDGCC=g++-11 $0)
override the version on the command line, e.g.: OLDGCC=g++-11 $0
EOF
  exit 1
fi

W=$(mktemp -d); cd "$W"
echo "workdir: $W"
echo "old g++: $($OLDGCC --version | head -1)"
echo "default g++: $(g++ --version | head -1)"

cat > companion.cxx <<'CXX'
#include <regex>
extern "C" void companion_touch() {
  static std::regex r("(a)|(b)|(c)"); (void)r;
}
CXX

"$OLDGCC" -shared -fPIC -O2 companion.cxx -o libcompanion.so

python3 -m venv .venv && . .venv/bin/activate
pip install --quiet 'vtk>=9.6'

PYCALL='import vtk; r=vtk.vtkImageReader2(); r.ComputeInternalFileName(0); print("VTK",vtk.VTK_VERSION,"ok:",repr(r.GetInternalFileName()))'

echo; echo "=== 1. bare run ==="
python -c "$PYCALL"

echo; echo "=== 2. companion preloaded (LD_PRELOAD) ==="
err=$(mktemp)
set +e
LD_PRELOAD=$PWD/libcompanion.so python -c "$PYCALL" 2> >(tee "$err" >&2)
rc=$?
set -e
echo
if [$rc -eq 0]; then
  echo ">>> RESULT: did NOT reproduce (clean exit)."
  echo ">>> Try a wider GCC gap: OLDGCC=g++-9 (or g++-7) $0"
elif [$rc -ge 128]; then
  sig=$((rc - 128)); name=$(kill -l "$sig" 2>/dev/null || echo "?")
  case "$name" in
    SEGV|ABRT|BUS|ILL|FPE)
      echo ">>> RESULT: BUG REPRODUCED."
      echo ">>> Process killed by SIG$name (signal $sig, exit $rc)."
      if grep -q 'bad_alloc\|terminate called' "$err"; then
        echo ">>> libstdc++ aborted from an uncaught exception (e.g. std::bad_alloc)."
        echo ">>> This is the same ODR-drift class as the SIGSEGV seen in the field."
        echo ">>> _Compiler is built with one layout, walked with another;"
        echo ">>> the corrupted state can deref a bad pointer (SIGSEGV) OR request"
        echo ">>> an absurd allocation (bad_alloc -> terminate -> SIGABRT)."
      else
        echo ">>> Same crash class as Murat's field SIGSEGV in vtkStringFormatter."
      fi
      ;;
    *)
      echo ">>> RESULT: killed by SIG$name (signal $sig); inconclusive."
      ;;
  esac
else
  echo ">>> RESULT: exited $rc (non-zero but not a signal). Not a crash; probably a Python-level error."
fi
rm -f "$err"

echo; echo "=== 3. which library wins the _Compiler template symbol ==="
for env in "" "LD_PRELOAD=$PWD/libcompanion.so"; do
  echo "-- env: ${env:-none}"
  env $env gdb --batch -q \
    -ex 'set breakpoint pending on' \
    -ex 'b vtkImageReader2::ComputeInternalFileName' \
    -ex 'run' \
    -ex "info sym 'std:: __detail::_Compiler<std::__ cxx11::regex_traits<char> >::_M_alternative()'" \
    --args python -c "$PYCALL" 2>/dev/null | grep -E '^\$|in section|libcompanion|libvtk|libstdc' || true
done

```

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [May 12, 2026, 9:06pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/25 "2026-05-12T21:06:55Z")

</div>

> [@pieper](#):
>
> @muratmaga can you confirm?

Yep, disabling surface smoothing makes rendering possible.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [May 13, 2026, 2:44pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/26 "2026-05-13T14:44:01Z")

</div>

I filed an issue on the vtk tracker here: [https://gitlab.kitware.com/vtk/vtk/-/work\_items/20047](https://gitlab.kitware.com/vtk/vtk/-/work_items/20047)

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [May 13, 2026, 7:23pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/27 "2026-05-13T19:23:17Z")

</div>

@pieper Can you try uninstalling the VTK Python package that Slicer builds and instead pip install the VTK whl from PyPI? I would suspect there are some differences in how we configure and build the whl versus VTK.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [May 13, 2026, 7:39pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/28 "2026-05-13T19:39:25Z")

</div>

@jamesobutler it should be the same either way. The script I sent uses the VTK pip package and a python that is independent to Slicer.

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [May 14, 2026, 1:01am UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/29 "2026-05-14T01:01:18Z")

</div>

@pieper I asked because I was thinking about

`_GLIBCXX_USE_CXX11_ABI=0`

> **[Verifying connection...](https://gitlab.kitware.com/vtk/vtk/-/work_items/1991)**

Does the issue happen in Slicer core with no extensions installed with its self-built VTK whl or does a Slicer extension install a specific VTK whl that pulls from PyPI that is using a different `_GLIBCXX_USE_CXX11_ABI`?

> <https://github.com/Slicer/Slicer/pull/8168>
>
> This commit introduces the ability to configure a \`\_manylinux\` module in the Sli…cer build system to enhance compatibility when installing binary Python wheels.
> 
> This update resolves potential issues with installing Python wheels built for newer GLIBC versions or ABIs, which could cause crashes in environments with older configurations.
> 
> Specifically, installing \`manylinux\_2\_28\_x86\_64\` ITK wheels compiled with \`\_GLIBCXX\_USE\_CXX11\_ABI=1\` was causing segmentation faults in the \_Stable\_ Slicer version, which is compiled with \`\_GLIBCXX\_USE\_CXX11\_ABI=0\`. The \`\_manylinux\` module ensures that \`manylinux\_2\_17\_x86\_64\` ITK wheels are always installed, even when Slicer and its associated Python interpreter are executed on newer operating systems.
> 
> The \`\_manylinux.py\` module is dynamically generated during the build process and ensures that Python packages installed via \`pip\` are compatible with the GLIBC version used in the Slicer build environment.
> 
> \### Summary of Changes
> 
> \*\*\`External\_python.cmake\`\*\*:
> \- Added logic to configure \`\_manylinux.py\` for Linux-based build environments.
> \- By default, \`\_manylinux.py\` is generated. If disabled using the CMake option \`PYTHON\_CONFIGURE\_MANYLINUX\_MODULE\`, any existing \`\_manylinux.py\` module is removed to prevent inadvertent impacts on Python package installations.
> \- Introduced a CMake option \`PYTHON\_REMOVE\_MANYLINUX\_MODULE\_IF\_EXISTS\` to allow users to disable the removal of an existing \`\_manylinux.py\` module.
> 
> \*\*\`python\_configure\_manylinux\_module.cmake\`\*\*:
> \- New CMake script to detect the system's GLIBC version using \`ldd\`.
> \- Dynamically generates the \`\_manylinux.py\` module, which includes:
> - A \`manylinux\_compatible\` function to override the default behavior of \`pip\` for checking compatibility of manylinux tags.
> - Embedded documentation and compatibility checks to prevent crashes caused by mismatched ABI or GLIBC versions.
> 
> By restricting installed packages to compatible manylinux tags, this update ensures stability and reliability for Python packages in the Slicer ecosystem.
> 
> \### References
> 
> \- \[PEP 600: Manylinux Platform Tag\](https://peps.python.org/pep-0600/)
> \- \[GCC Dual ABI Documentation\](https://gcc.gnu.org/onlinedocs/libstdc++/manual/using\_dual\_abi.html)

> [@Slicer Build Environment Upgraded to \`qt5-almalinux8-gcc14\`](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802):
>
> The build environment used for generating Slicer Preview and its extensions has been upgraded from qt5-centos7-gcc7 to qt5-almalinux8-gcc14. This update brings improved C++ standards support, better compatibility with modern systems, and eliminates complications related to the Dual ABI issue previously discussed [here](https://discourse.slicer.org/t/temporary-disabling-of-stable-extension-builds-in-preparation-for-slicer-5-8-release-visual-studio-update/41207/7). Comparison of Build Environments Build Environment Minimum Required glibc Manylinux Policy GCC Version Compatible Systems qt5-centos7-gcc7 2.17 manylinux2014, manylinux\_2…

Latest VTK on PyPI only provide x86\_64 whls that are manylinux\_2\_17 as they provide manylinux\_2\_28 whl for ARM64 Linux only. [vtk · PyPI](https://pypi.org/project/vtk/9.6.1/#files)

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [May 14, 2026, 6:21am UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/30 "2026-05-14T06:21:01Z")

</div>

I’ve checked and libQt_WebEngineCore.so._ contains incorrectly exported std symbols until Qt-6.6, but the problem got fixed in Qt-6.7. So, the simplest fix the crash in Slicer would be to upgrade to Qt-6.7 or higher.

It is nice if we also fix this in VTK, because that way we avoid crashes in the future when any other software component incorrectly exports symbols. The flags that were proposed above (CMAKE\_CXX\_VISIBILITY\_PRESET, CMAKE\_VISIBILITY\_INLINES\_HIDDEN, etc.) were already set, but Claude suggested a [small, localized change that made the global std:: symbols disappear](https://github.com/Kitware/VTK/commit/cd15bea2b99bf3feaf51ff332fc5ae7d7199a4ef). – @Sam_Horvath or @ebrahim could you patch VTK on factory with this commit and create a nightly linux build with it to confirm the fix and test that there are no regressions?

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [May 14, 2026, 1:00pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/31 "2026-05-14T13:00:13Z")

</div>

If making a custom build today is not feasible, we could just apply this patch to Slicer/VTK and check the build tomorrow.

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [May 14, 2026, 1:45pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/32 "2026-05-14T13:45:49Z")

</div>

Here’s the correct gitlab link that I was trying to post regarding a:

> Mixing old and new ABIs in the same application causes crashes in `std::regex` due to a known libstdc++ bug:

> **[Verifying connection...](https://gitlab.kitware.com/vtk/vtk/-/work_items/19919)**

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [May 27, 2026, 1:28pm UTC](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974/33 "2026-05-27T13:28:43Z")

</div>

Issue is being tracked here:

> <https://github.com/Slicer/Slicer/issues/9181>
>
> @lassoan

[Previous page](https://discourse.slicer.org/t/volume-rendering-broken-in-latest-linux-previews/46974.md?page=1)