fix: Fix segfault during shutdown when using Triton metrics in Python backend

[aleksn7]

Problem
When shutting down the Triton Inference Server with Python backend while using Triton metrics, a segmentation fault occurs. This happens because Metric::Clear attempts to access the Stub singleton during the Stub destructor execution.

Stack trace:

#0  triton::backend::python::Metric::SaveToSharedMemory()
#1  triton::backend::python::Metric::Clear()
#2  triton::backend::python::MetricFamily::~MetricFamily()
#3  std::_Sp_counted_base<>::_M_release()
#4  pybind11::class_<MetricFamily>::dealloc()
#5  pybind11_object_dealloc()
#6  libpython3.12.so.1.0
#7  libpython3.12.so.1.0
#8  triton::backend::python::Stub::~Stub()
#9  main()

Solution
Added a new DestroyPythonObjects() method to the Stub class that explicitly releases all Python objects before the Stub destructor is invoked. This ensures proper destruction order:

DestroyPythonObjects() is called first, releasing all Python-bound objects (including MetricFamily instances)
Stub::~Stub() is called afterward, when no Python objects depend on it
This approach guarantees that MetricFamily and other Python objects are fully destroyed while Stub is still valid and accessible.

To reproduce
Run triton server with custom metric example model and shut it down by kill -2 <main triton server process pid>

[whoisj]

@aleksn7 thank you for your contribution. Have you completed the required steps outlined in our Contributing section?

Specifically, have you submitted a signed CLA? If not, please do so.

[Copilot]

Pull request overview

Fixes a shutdown-time segmentation fault in the Python backend when Triton custom metrics are enabled by ensuring Python-bound objects are released in a safe order relative to the Stub singleton teardown.

Changes:

• Added Stub::DestroyPythonObjects() to explicitly drop Python-owned objects before Stub destruction.
• Updated Stub::DestroyInstance() to call DestroyPythonObjects() prior to resetting the singleton.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/pb_stub.h	Declares the new DestroyPythonObjects() API and documents intended destructor ordering.
src/pb_stub.cc	Calls DestroyPythonObjects() during singleton destruction and implements the cleanup routine.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[whoisj]

LGTM. @yinggeh can you add you review as well?

[whoisj]

This is still blocking:

@aleksn7 thank you for your contribution. Have you completed the required steps outlined in our Contributing section?

Specifically, have you submitted a signed CLA? If not, please do so.

[aleksn7]

This is still blocking:

@aleksn7 thank you for your contribution. Have you completed the required steps outlined in our Contributing section?

Specifically, have you submitted a signed CLA? If not, please do so.

I'm working on it

[aleksn7]

@whoisj Hello!
I signed CLA

[whoisj]

CI Pipeline ID: 52832251

[aleksn7]

CI Pipeline ID: 52832251

Hi! Do you have any updates on this?

[whoisj]

@aleksn7, apologies for the delay as we've been off work for the past five days. Unfortunately, there are test failures in our CI currently that while unrelated to this PR, are blocking my ability to validate this PR. We'll return to this PR as soon as these test failures have been resolved. Again, my apologies for the delay.

[karljang]

Hi @whoisj,
I'm curious about the status of this PR.
I believe it may fix NVBug 6405758. That bug also appears to correspond to the TensorRT-LLM shutdown core dump mentioned in the Triton 2.70.0 release notes.

[karljang]

@pskiran1 , could you please help with this PR? thank you!

[pskiran1]

@pskiran1 , could you please help with this PR? thank you!

@karljang, sorry for the delay. It LGTM.
@yinggeh , could you please add your review.
Thank you.

[karljang]

@yinggeh , could you please review this PR, thanks