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.

[whoisj]

this makes sense, but please move the call to Stub::DestroyInstance().

[aleksn7]

Done ✅

[whoisj]

this makes sense, but please move this call to Stub::DestroyInstance().

[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.

[Copilot]

Stub::DestroyInstance() unconditionally dereferences stub_instance. If DestroyInstance() is called before GetOrCreateInstance() (or called twice), this will crash. Add a null check (e.g., early-return if !stub_instance) before calling DestroyPythonObjects() / reset().

Suggested change

	{
	{
	if (!stub_instance) {
	return;
	}

[aleksn7]

Done ✅

[Copilot]

DestroyPythonObjects() only clears async_event_loop_, background_futures_, and model_instance_, but Stub also owns other py::object members (deserialize_bytes_, serialize_bytes_). If those remain non-empty, they will be decref'd later during Stub destruction (potentially after py::scoped_interpreter teardown / without the GIL), which can still segfault. Consider moving/clearing all py::object members here (and ideally reuse this helper from ~Stub() to keep the cleanup logic in one place).

Suggested change

	py::object model_instance_local(std::move(model_instance_));
	py::object model_instance_local(std::move(model_instance_));
	py::object deserialize_bytes_local(std::move(deserialize_bytes_));
	py::object serialize_bytes_local(std::move(serialize_bytes_));

[aleksn7]

@whoisj What do you think about this? Should we listen copilot here?

[whoisj]

if the other fields are not a problem, then it doesn't matter, honestly.

[Copilot]

The comment mentions Stub::GetOrCreate, but the singleton accessor is Stub::GetOrCreateInstance(). Update the comment to match the actual API to avoid confusion when debugging shutdown/destructor-order issues.

Suggested change

	/// call Stub::GetOrCreate.
	/// call Stub::GetOrCreateInstance().

[aleksn7]

Done ✅

[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