[Isaac Sim 6.0.1] Reliable segfault on Timeline Stop when "Enable GPU Dynamics" is on (regression from 5.1.0)

[MohammadrezaFar]

Isaac Sim Version

[X] 6.0.1
[ ] 6.0.0
[ ] 5.1.0
[ ] 5.0.0
[ ] 4.5.0
[ ] 4.2.0
[ ] 4.1.0
[ ] 4.0.0
[ ] 4.5.0
[ ] 2023.1.1
[ ] 2023.1.0-hotfix.1
[ ] Other (please specify):

Operating System

[X] Ubuntu 24.04
[ ] Ubuntu 22.04
[ ] Ubuntu 20.04
[ ] Windows 11
[ ] Windows 10
[ ] Other (please specify):

GPU Information

• GPU 1Model: NVIDIA GeForce RTX 4070 (AD104)Driver Version: nvidia (Generic kernel driver name)
• GPU 2Model: NVIDIA GeForce RTX 3080 Lite Hash Rate (GA102)Driver Version: nvidia (Generic kernel driver name)
• Integrated Server VideoModel: ASPEED Graphics FamilyDriver Version: ast

Topic Description

Detailed Description

Summary

Isaac Sim 6.0.1, running headless in Docker with the WebRTC streaming client, crashes with a segmentation fault 100% of the time when stopping the timeline (Stop button or omni.timeline.get_timeline_interface().stop()), as long as the scene has an actively-stepping PhysX simulation with Enable GPU Dynamics turned on. Disabling Enable GPU Dynamics on the PhysicsScene prim (keeping physics running on CPU) makes the exact same scenes Play/Stop reliably with no crash. This setup worked without issue for a long time on Isaac Sim 5.1.0 with identical hardware, driver, and Docker configuration.

I've isolated this down to a minimal repro and would like to know whether this is a known regression, whether disabling GPU Dynamics is the recommended workaround, and whether a fix is planned.

System / Environment

• Isaac Sim: 6.0.1 (container image nvcr.io/nvidia/isaac-sim:6.0.1)
  • appVersion = 6.0.1, Kit Version = 110.1.2+production.326809.f9bf0dda.gl
  • lib_isaacSim_buildVersion = 6.0.1-rc.7, lib_isaacSim_buildHash = 32955d8
  • lib_physx_buildVersion = 110.1.13
  • CarbSdkVersion = 210.1.11+release.13746.80f6dc72.gl
• Deployment: headless, in a custom Docker container built FROM nvcr.io/nvidia/isaac-sim:6.0.1, launched via runheadless.sh → isaacsim.exp.full.streaming.kit, connected to via the Isaac Sim WebRTC Streaming Client
• Container runtime: nvidia Docker runtime, container runs as non-root user, --/renderer/multiGpu/enabled=true
• OS: Ubuntu 24.04.3 LTS (Noble Numbat), kernel 6.8.0-124-generic
• CPU: AMD EPYC 7401P 24-Core Processor (24 physical / 48 logical cores), 128 GB RAM
• GPU: Dual GPU, driver 580.82.07, CUDA 13.0, Graphics API: Vulkan

|---------------------------------------------------------------------------------------------|
| Driver Version: 580.82.07     | Graphics API: Vulkan
|=============================================================================================|
| GPU | Name                             | Active | LDA | GPU Memory | Vendor-ID | LUID       |
|     |                                  |        |     |            | Device-ID | UUID       |
|     |                                  |        |     |            | Bus-ID    |            |
|---------------------------------------------------------------------------------------------|
| 0   | NVIDIA GeForce RTX 4070          | Yes: 0 |     | 12528   MB | 10de      | 0          |
|     |                                  |        |     |            | 2786      | 32c05a89.. |
|     |                                  |        |     |            | 21        |            |
|---------------------------------------------------------------------------------------------|
| 1   | NVIDIA GeForce RTX 3080          | Yes: 1 |     | 10486   MB | 10de      | 0          |
|     |                                  |        |     |            | 2216      | bb59c536.. |
|     |                                  |        |     |            | 42        |            |
|=============================================================================================|

This exact dual-GPU configuration (with multiGpu/enabled=true) was used for a long time on Isaac Sim 5.1.0 on the same server, same driver, same Docker setup, with no crashes of this kind.

Steps to Reproduce

1. Fresh container (docker compose down + build + up, no cached state — ~/.local/share/ov/data is not volume-mounted, so every run starts cold; autoloadExts is empty, confirmed via crash-report metadata).
2. Create a new scene: a ground plane + a single mesh with a rigid body + collider preset applied. No materials, no third-party extensions.
3. Ensure the PhysicsScene's Enable GPU Dynamics is on (the default).
4. Click Play.
5. Click Stop — or, equivalently, run omni.timeline.get_timeline_interface().stop() from the Script Editor.
6. → Segmentation fault, container exits, Docker restarts it (restart: unless-stopped).

Isolation performed

I went through a fairly thorough elimination process across several sessions before landing on the actual cause:

Variable tested	Result
Third-party extensions (e.g. Cesium for Omniverse) present vs. completely absent (fresh container, empty autoloadExts)	No difference — crashes either way
Scene has MDL materials bound vs. no materials at all	No difference — crashes either way
Stop via toolbar UI button vs. omni.timeline.get_timeline_interface().stop() via Script Editor	No difference — crashes either way (confirms it's not a UI-command-specific bug)
Complex scene (full robot/vessel simulation with a custom buoyancy script) vs. minimal scene (ground plane + one rigid body)	No difference — crashes either way
Physics "Toggle Executive" off (physics scene present but not stepping)	No crash
Physics backend set to None	No crash (expected, no physics engine active)
PhysicsScene Enable GPU Dynamics ticked (default)	Crashes on Stop, 100% of the time
PhysicsScene Enable GPU Dynamics unticked (CPU PhysX, physics still actively stepping)	No crash — Play/Stop cycles work reliably
Wrapping the entrypoint with xvfb-run to provide a virtual display	Did not resolve it, but a separate xvfb-run startup issue on my end means this test isn't fully conclusive — noting for completeness, not as a ruled-out variable

So the crash appears tied specifically to GPU-accelerated PhysX pipeline teardown when the timeline is stopped, not to rendering, materials, or any third-party extension.

Crash signature (consistent across 4 separate captured logs)

• carb.crashreporter-breakpad.plugin catches a Segmentation fault (core dumped).
• The crash dump itself has repeatedly failed to contain a usable backtrace (dump file size is 0 bytes, file is readable in earlier captures; later captures didn't complete the upload before the container was torn down). I have not yet been able to attach a debugger in time (open to suggestions on the best way to do this reliably in a headless streaming container, if there's a documented approach).
• In every log, roughly 3 seconds before the segfault, carb.windowing-glfw.plugin logs a GLFW initialization failed warning — mid-session, not at startup (this is distinct from the normal, documented, harmless startup-time GLFW warning for headless mode). This ~3-second gap between that warning and the segfault was consistent across all 4 logs I captured (regardless of scene, script, or elapsed session time — seen at roughly the 500s, 750s, 1036s, and 754s marks in different sessions). I'm not sure if this is causally related to the GPU Dynamics teardown or a separate symptom that happens to be time-correlated — flagging it in case it's a useful clue.
• lastCommand in the crash metadata is ToolbarStopButtonClicked when Stop is triggered via the UI, and (as expected, since API calls don't go through Kit's Command History) stays at the previous command when Stop is triggered via script — but the crash happens either way.

Question for NVIDIA / the community

• Is this a known regression in 6.0.1's GPU PhysX teardown path when the timeline stops?
• Is disabling Enable GPU Dynamics the currently recommended workaround, or is there a better one?
• Is there a documented/reliable way to attach a debugger (gdb/py-spy) to a headless Isaac Sim container running via the WebRTC streaming app, to capture a real backtrace for this? Happy to do that and share it if it'd help triage.

Happy to share full logs, my Dockerfile, or run further tests — this is 100% reproducible on my end so I can iterate quickly.

[michaellin6]

Hi @MohammadrezaFar thank you for the detailed info on the crash issue you are running into. Can you share the full logs from your runs and the Dockerfile you are using? Thank you.

[MohammadrezaFar]

Hi @michaellin6
Thanks for your response.
I created a .ZIP file that contains more info about our setup and logs.
nvidia-isaac-sim-crash-report.zip

[michaellin6]

Hi @MohammadrezaFar,

Thank you for providing the logs and Docker configuration. We were not able to reproduce the crash on our single-GPU Isaac Sim 6.0.1 setup, but your dual-GPU configuration appears to be an important part of the trigger.

We found a related multi-GPU PhysX issue in which stopping the Timeline can crash while releasing a GPU simulation. A fix for that issue is expected in the Physics version included with Isaac Sim 6.1, which is scheduled to be released today or tomorrow. We cannot confirm that your crash has the same root cause without a matching native backtrace, but the version, multi-GPU configuration, GPU Dynamics dependency, and Stop-time failure are closely aligned.

Once Isaac Sim 6.1 is publicly available, please test the same scene with both GPU Dynamics and multi-GPU enabled and let us know whether the crash is resolved.

Until then, the preferred workaround is to run Isaac Sim in single-GPU mode while keeping GPU Dynamics enabled:

./runheadless.sh --/renderer/multiGpu/enabled=false

If single-GPU execution is not suitable, continue using CPU PhysX by disabling Enable GPU Dynamics, which you have already confirmed avoids the crash.

If the issue remains in Isaac Sim 6.1, please share the new log and crash dump ID. It would also be helpful to confirm whether --/renderer/multiGpu/enabled=false prevents the crash on the affected system.

[MohammadrezaFar]

Hi @michaellin6 ,

Thank you for the detailed follow-up and for tracking down the related multi-GPU PhysX issue — I can confirm the crash is resolved on my setup.

What I changed:

Upgraded the host GPU driver from 580.82.07 → 595.84 (CUDA 13.2), per the 6.0.1 requirements page.
Migrated from Isaac Sim 6.0.1 → 6.1.0.

Result: With both Enable GPU Dynamics ticked and multi-GPU rendering enabled (--/renderer/multiGpu/enabled=true), I can now start and stop the simulation repeatedly with no crash. This is on the same dual-GPU system as before (RTX 4070 + RTX 3080), the same Docker/headless/WebRTC streaming setup, and the same scenes that previously segfaulted on Stop 100% of the time — including both the full WAM-V buoyancy scene and the minimal ground-plane-plus-rigid-body repro.

So the behaviour matches what you predicted for the Physics fix shipped in 6.1. Since I changed both the driver and the Isaac Sim version in the same step, I can't attribute the fix to one or the other individually — if it's useful for your triage to know whether 6.1.0 alone resolves it on the older 580.x driver, let me know and I can try to test that combination separately.

One note on your other question: I was not able to test --/renderer/multiGpu/enabled=false with GPU Dynamics enabled on the affected 6.0.1 + 580.82.07 configuration before migrating, so I unfortunately can't confirm whether that workaround alone prevented the crash on my system. Apologies — I'd already moved to 6.1.0 by the time I got to it.

Thanks again to you and the team for the quick turnaround and for the clear workarounds in the meantime. Happy for this to be closed from my side.