[BUG] pyservicemaker: Pipeline.stop() keeps the GIL and deadlocks against a Python probe
メンテナーはふだん 1 日以内に返信
@nvqiezi がすでに取り組んでいます。
2026年10月27日 から。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 78/100
調査の方向性
src/service-maker/sources/python/src/bindings/pipeline.h の Pipeline.stop() バインディングの周辺を読み、GIL を解放する隣接するバインディングと比較してください。Issue には、プローブを使ってデッドロックを再現するための Python 再現スクリプトと Docker コマンドが含まれています。実行中に stop() が GIL を解放するようバインディングを更新し、プローブのケースがハングせずに完了することを確認してください。
索引モデルが issue の本文から書いたものです。
説明
Describe the bug
Pipeline.stop() in pyservicemaker keeps the GIL while it sends EOS into the pipeline. If a streaming thread is inside a Python probe (BufferOperator, BatchMetadataOperator) at that moment, the two threads deadlock: stop() waits for a lock that the streaming thread holds, and the streaming thread waits for the GIL. Every Python thread then freezes, so a Python timeout or watchdog thread cannot help either.
The binding is in src/service-maker/sources/python/src/bindings/pipeline.h: .def("stop", &Pipeline::stop, ...) has no py::gil_scoped_release, while wait, seek, start_recording and stop_recording next to it do. Pipeline::stop() calls gst_element_send_event(pipeline, gst_event_new_eos()), which blocks while the source's streaming thread is in gst_pad_push.
Steps/Code to reproduce bug
Save as repro.py:
import faulthandler
import sys
import threading
import time
from pyservicemaker import BufferOperator, Pipeline, Probe
class Count(BufferOperator):
def __init__(self):
super().__init__()
self.buffers = 0
def handle_buffer(self, buffer):
self.buffers += 1
return True
runs = int(sys.argv[1])
with_probe = sys.argv[2] == "probe"
for run in range(1, runs + 1):
count = Count()
pipeline = Pipeline(f"stop-{run}")
# An unpaced source, so the streaming thread calls the probe all the time.
pipeline.add("videotestsrc", "src", {"pattern": 2})
pipeline.add("fakesink", "sink", {"sync": False})
pipeline.link("src", "sink")
if with_probe:
pipeline.attach("src", Probe("count", count))
waiter = threading.Thread(target=pipeline.wait)
pipeline.start()
time.sleep(0.5)
# Prints every thread's stack and exits if stop() and wait() do not finish in 10 s.
faulthandler.dump_traceback_later(10, exit=True)
started = time.monotonic()
waiter.start()
pipeline.stop()
waiter.join()
faulthandler.cancel_dump_traceback_later()
print(f"run {run}: stopped in {time.monotonic() - started:.2f} s after {count.buffers} buffers", flush=True)
print("all runs stopped")
Run it in the stock container (pyyaml is installed first because import pyservicemaker needs it, see #98):
docker run --rm --gpus all -v "$PWD":/repro --entrypoint bash nvcr.io/nvidia/deepstream:9.1-triton-multiarch \
-c "pip install -q --break-system-packages pyyaml && python3 /repro/repro.py 10 probe"
With no-probe in place of probe, all 10 runs stop at once. With the probe, stop() deadlocks within the first two runs (on run 1 or run 2 in three attempts):
Posted EOS to stop pipeline
run 1: stopped in 0.00 s after 5407 buffers
Timeout (0:00:10)!
File "/usr/local/lib/python3.12/dist-packages/pyservicemaker/pipeline.py", line 201 in wait
File "/usr/local/lib/python3.12/dist-packages/pyservicemaker/pipeline.py", line 214 in stop
File "/repro/repro.py", line 38 in <module>
Native stacks of the deadlocked process (gdb -p <pid> -batch -ex "thread apply all bt", run with --cap-add SYS_PTRACE), trimmed to the frames that matter. The main thread holds the GIL and waits for the stream lock:
#1 pthread_mutex_lock () at libc.so.6
#3 gst_element_send_event () at libgstreamer-1.0.so.0
#6 deepstream::Pipeline::stop() () at libnvds_service_maker.so
#7 pybind11::cpp_function::cpp_function<deepstream::Pipeline&, PipelineWrapper, ...>::{lambda(PipelineWrapper*)#1}::operator() at _pydeepstream.so
The source's streaming thread holds the stream lock and waits for the GIL:
Thread 4 (LWP 101) "src:src"
#1 pthread_cond_timedwait () at libc.so.6
#3 PyEval_AcquireThread ()
#4 pybind11::gil_scoped_acquire::gil_scoped_acquire() () at _pydeepstream.so
#5 PyBufferOperator::handle_buffer(deepstream::Buffer) () at _pydeepstream.so
#6 BufferOperator_::handleBuffer(deepstream::BufferProbe&, deepstream::Buffer&) () at _pydeepstream.so
#7 deepstream::genric_probe_callback(_GstPad*, _GstPadProbeInfo*, void*) () at libnvds_service_maker.so
#12 gst_pad_push () at libgstreamer-1.0.so.0
Expected behavior
stop() releases the GIL while it runs, as wait() does, so a probe can finish and stop() returns:
.def("stop", [](PipelineWrapper& self) {
py::gil_scoped_release release;
self.stop();
}, pydeepstreamdoc::pipeline::PipelineDoc::stop)
(Pipeline.stop in pipeline.py already returns self, so the binding does not need to return the pipeline.)
Environment details
- Environment location: Docker on bare-metal (Ubuntu 26.04.1 LTS host, RTX A4000 Laptop GPU, driver 595.99.02)
- Method of DeepStream install: Docker,
nvcr.io/nvidia/deepstream:9.1-triton-multiarch(digestsha256:fd31f5b44ababdbdee8cd397a375e888191b49e402ac237254a4cdc239130f5b), DeepStream 9.1.0, pyservicemaker 0.0.1, TensorRT 10.16.0.72, CUDA 13.2 - Docker command: see the steps above
scripts/print_env.shoutput, run inside the same container:
Click here to see environment details
**git*** Not inside a git repository ***OS Information*** DISTRIB_ID=Ubuntu DISTRIB_RELEASE=24.04 DISTRIB_CODENAME=noble DISTRIB_DESCRIPTION="Ubuntu 24.04.4 LTS" PRETTY_NAME="Ubuntu 24.04.4 LTS" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04.4 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=noble LOGO=ubuntu-logo Linux b5ade298bb5a 7.0.0-38-generic #38-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 4 09:10:14 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux ***GPU Information*** Thu Oct 22 14:52:51 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 595.99.02 Driver Version: 595.99.02 CUDA Version: 13.2 | +-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA RTX A4000 Laptop GPU Off | 00000000:01:00.0 Off | N/A | | N/A 63C P0 25W / 80W | 161MiB / 8192MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | No running processes found | +-----------------------------------------------------------------------------------------+ ***CPU*** Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 39 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 16 On-line CPU(s) list: 0-15 Vendor ID: GenuineIntel Model name: 11th Gen Intel(R) Core(TM) i9-11950H @ 2.60GHz CPU family: 6 Model: 141 Thread(s) per core: 2 Core(s) per socket: 8 Socket(s): 1 Stepping: 1 CPU(s) scaling MHz: 42% CPU max MHz: 5000.0000 CPU min MHz: 800.0000 BogoMIPS: 5222.40 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l2 cdp_l2 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves split_lock_detect user_shstk dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid movdiri movdir64b fsrm avx512_vp2intersect md_clear ibt flush_l1d arch_capabilities Virtualization: VT-x L1d cache: 384 KiB (8 instances) L1i cache: 256 KiB (8 instances) L2 cache: 10 MiB (8 instances) L3 cache: 24 MiB (1 instance) NUMA node(s): 1 NUMA node0 CPU(s): 0-15 Vulnerability Gather data sampling: Vulnerable Vulnerability Ghostwrite: Not affected Vulnerability Indirect target selection: Mitigation; Aligned branch/return thunks Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Mmio stale data: Not affected Vulnerability Old microcode: Not affected Vulnerability Reg file data sampling: Not affected Vulnerability Retbleed: Not affected Vulnerability Spec rstack overflow: Not affected Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; PBRSB-eIBRS SW sequence; BHI SW loop, KVM SW loop Vulnerability Srbds: Not affected Vulnerability Tsa: Not affected Vulnerability Tsx async abort: Not affected Vulnerability Vmscape: Not affected ***CMake*** /usr/bin/cmake cmake version 3.28.3 CMake suite maintained and supported by Kitware (kitware.com/cmake). ***g++*** /usr/bin/g++ g++ (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ***nvcc*** /usr/local/cuda/bin/nvcc nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2026 NVIDIA Corporation Built on Mon_Mar_02_09:52:23_PM_PST_2026 Cuda compilation tools, release 13.2, V13.2.51 Build cuda_13.2.r13.2/compiler.37434383_0 ***Python*** ***Environment Variables*** PATH : /opt/proto/bin:/opt/tritonserver/bin:/usr/local/nvidia/bin:/usr/local/cuda/bin:/usr/local/mpi/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/ucx/bin:/opt/amazon/efa/bin:/.local/bin LD_LIBRARY_PATH : /opt/tritonserver/lib:/opt/tritonclient/lib:/usr/src/tensorrt/lib:/opt/riva/lib:/usr/local/cuda-13/lib64:/usr/lib/x86_64-linux-gnu:/opt/hpcx/ucc/lib/:/opt/hpcx/ucx/lib/:/usr/local/cuda/compat/lib:/usr/local/nvidia/lib:/usr/local/nvidia/lib64:/.local/lib NUMBAPRO_NVVM : NUMBAPRO_LIBDEVICE : CONDA_PREFIX : PYTHON_PATH : conda not found ***pip packages*** /usr/bin/pip Package Version ------------------- --------------- annotated-doc 0.0.4 annotated-types 0.7.0 anyio 4.12.1 apparmor 4.0.1 certifi 2026.2.25 cupy-cuda13x 13.6.0 distlib 0.4.0 distro 1.9.0 fastapi 0.138.1 fastrlock 0.8.3 filelock 3.25.2 h11 0.16.0 httpcore 1.0.9 httpx 0.27.2 idna 3.11 iniconfig 2.3.0 jaraco.context 6.1.0 jiter 0.13.0 LibAppArmor 4.0.1 numpy 1.26.4 openai 1.107.3 packaging 24.0 partial-json-parser 0.2.1.1.post7 pip 24.0 platformdirs 4.9.4 pluggy 1.6.0 pydantic 2.10.6 pydantic_core 2.27.2 Pygments 2.19.2 pyservicemaker 0.0.1 pytest 9.0.2 python-apt 2.7.7+ubuntu5.2 python-discovery 1.1.3 scipy 1.16.3 setuptools 78.1.1 sniffio 1.3.1 starlette 0.52.1 tqdm 4.67.3 tritonfrontend 2.67.0 tritonserver 0.0.0 typing_extensions 4.15.0 typing-inspection 0.4.2 virtualenv 21.2.0 wheel 0.42.0
Additional context
Any Python application that stops a pipeline with probes attached can hit this; the faster the source, the more likely. A service that stops on SIGTERM (for example in Kubernetes) then hangs until it is killed, and its sinks are not finalized. Calling stop() from another Python thread does not help, because the held GIL freezes every Python thread. The only workaround we found is a watchdog that runs outside Python, such as faulthandler.dump_traceback_later(timeout, exit=True), which kills the process.
- 主要言語
- C++
- スター
- 283
- フォーク
- 62
- 平均マージ
- 2時間 24分
- マージ済み PR(30日)
- 20
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
NVIDIA/DeepStream のほかの issue
-
bug
難易度 1/5 1時間未満 初心者へのやさしさ 84/100
NVIDIA/DeepStream#78 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
NVIDIA/DeepStream#103 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
NVIDIA/DeepStream#101 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
NVIDIA/DeepStream#100 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] pyservicemaker: element errors never reach on_message, and a fatal error leaves wait() blocked forever対応中かも @nv-support が 1 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 50/100
NVIDIA/DeepStream#98 · コメント 2 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
NVIDIA/DeepStream の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
NVIDIA-Omniverse/PhysX#590 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
apache/rocketmq-clients#1469 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 9 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
compiler-explorer/compiler-explorer#9402 ·
メンテナーはふだん 1 日以内に返信
-
自定义颜色添加为常用颜色オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
mg-chao/snow-apps#2227 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信