Deterministic SIGSEGV in Method::execute_instruction via EventTracerProfileOpScope destructor — QNN restore-fails→DLC-fallback path

[ivaylo681-dev]

🐛 Describe the bug

Reproduce:
python mobilenet_v2.py --device <device_serial> --soc_model "SM8750" --build_folder /path/to/build-android -d /path/to/imagenet-mini/val
Setup: executorch @ latest main as of 2026-08-07, QAIRT SDK 2.49.0.260730, Android NDK r27c, arm64-v8a. Device: SM8750P.

Output:
[INFO] QnnContextCustomProtocol expected magic number: 0x5678abcd but get: 0x4034b50
[INFO] Deserializing processed data using Dlc
[WARNING] Failed to interpret QNN context binary. Error code 30010. Try verifying binary with online-prepare format.
[INFO] Skip qnn_graph_create, graph has already been composed from Dlc.
Segmentation fault

Reproduces identically with --online_prepare set.
Symbolized backtrace (via lldb-server on-device + host lldb, locally-built non-stripped binary):

• thread Add support for quantized LeakyReLU #1, stop reason = signal SIGSEGV (fault addr 0x7f3337ec0c1c)
  frame #0: EventTracer::event_tracer_profiling_level(this=0x00007f3337ec0c00) at event_tracer.h:529
  frame Add support for quantized LeakyReLU #1: EventTracerProfileOpScope::~EventTracerProfileOpScope(this=0x0000007fffffc9cf) at event_tracer_hooks.h:63
  frame Re-sync with internal repository #2: Method::execute_instruction(...) at method.cpp:1546
  frame Rename _pt2e to pt2e #3: Method::execute(...) at method.cpp:1758
  frame Add unlifting pass under private config #4: main(...) at qnn_executor_runner.cpp:607

Root cause found in source — backends/qualcomm/runtime/backends/QnnGraphCommon.cpp, QnnGraph::Configure():

Qnn_GraphHandle_t graph_handle = nullptr;
// ...
} else if (context_->GetCacheState() == QnnBackendCache::ONLINE_PREPARE) {
QNN_EXECUTORCH_LOG_INFO("Skip qnn_graph_create, graph has already been composed from Dlc.");
// graph_handle is never assigned in this branch
}
// ...
handle_[graph_name] = graph_handle; // stores nullptr when state == ONLINE_PREPARE

In the ONLINE_PREPARE branch, graph_handle stays nullptr and gets stored with no validation. Whatever later consumes it operates on a null/invalid handle — a sufficient, deterministic explanation for the crash.

Versions

Collecting environment information...
PyTorch version: 2.13.0+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 11 Pro (10.0.26100 64-bit)
GCC version: Could not collect
Clang version: Could not collect
CMake version: version 3.31.7
Libc version: N/A

Python version: 3.11.0 (main, Oct 24 2022, 18:26:48) [MSC v.1933 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.26100-SP0
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
Is XPU available: False
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: False
Caching allocator config: N/A

CPU:
Name: Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz
Manufacturer: GenuineIntel
Family: 205
Architecture: 9
ProcessorType: 3
DeviceID: CPU0
CurrentClockSpeed: 2901
MaxClockSpeed: 2901
L2CacheSize: 1536
L2CacheSpeed: None
Revision: None

Versions of relevant libraries:
[pip3] numpy==2.4.6
[pip3] onnx==1.22.0
[pip3] onnxruntime==1.27.0
[pip3] onnxslim==0.1.94
[pip3] optree==0.19.1
[pip3] torch==2.13.0
[pip3] torchvision==0.28.0
[conda] Could not collect

cc @larryliu0820 @JacobSzwejbka @lucylq @cccclai @winskuo-quic @shewu-quic @haowhsu-quic @DannyYuyang-quic @cbilgin @abhinaykukkadapu @psiddh

[adityaanikam]

Confirmed the exact lines: graph_handle is declared nullptr, and the ONLINE_PREPARE branch only logs, it's the one branch of the three that never assigns into it, while DESERIALIZE and SERIALIZE/MULTI_GRAPH both call QNN API functions that write into &graph_handle. Then handle_[graph_name] = graph_handle stores whatever came out with zero validation regardless of which branch ran.

What I can't trace without the QNN SDK is what should populate graph_handle in the ONLINE_PREPARE case, the log message says the graph was already composed from the Dlc file, so presumably there's a retrieval call somewhere else that's supposed to run here and doesn't, rather than this just needing a null check. Is the intended fix actually calling something like qnn_graph_retrieve in this branch too, or is a validation and clean failure the right scope here?

[ivaylo681-dev]

@adityaanikam ,
Good question, and honestly I don't have visibility into what QNN's DLC-compose flow is meant to produce internally — I have the QAIRT SDK's public headers and Python tooling, but not the implementation source behind libQnnHtp.so/libQnnSystem.so themselves, so I can't confirm what should populate graph_handle here.

My best guess, based on the pattern: since the log explicitly says the graph "has already been composed from the Dlc," there's likely a real handle sitting somewhere that should be retrieved (similar to DESERIALIZE's qnn_graph_retrieve call) rather than this being a "should have failed cleanly" case — but that's a guess, not something I can confirm from the outside.

To be clear on scope: I opened this specifically because I traced it while testing a workaround for #21586 (which remains my actual case) — I don't have a QNN-based production use case myself, so I don't have more to add here beyond what's already documented. Happy to test a patch if one gets proposed, but I'll leave the actual fix direction to whoever has the visibility to answer it properly.

Separately — and not meant to derail this specific thread — the underlying issue in #21586 (native libQnnHtp.so/libQnnSystem.so not recognizing soc_id=639 despite Qualcomm's own SDK tooling mapping it correctly to SM8750) is still open and hasn't had a concrete resolution yet. If anyone here has visibility into that native SoC-detection code, any input there would be genuinely appreciated.

[ivaylo681-dev]

Great, thanks for tracking that down and confirming — glad the trace was useful. As noted, this doesn't touch my actual case (#21586), so I'll leave the review/merge to you all. Appreciate the quick turnaround.

[nil-is-all]

@chenweng-quic assigning this issue to you for now, since you led the discussion in the original issue. Could you tag respective QNN PoCs to address this and review #21860?

[chenweng-quic]

@chenweng-quic assigning this issue to you for now, since you led the discussion in the original issue. Could you tag respective QNN PoCs to address this and review #21860?

sure, let me check