Fix SAM2 segmentation ASan crashes

[sjuxax]

Disable ORT graph optimization for the SAM2.1 encoder to avoid the ONNX Runtime 1.24.x session-init UAF, and keep dynamic decoder output shape buffers alive across dt_ai_run calls so ORT can write resolved dims safely during warmup and decode.

Co-authored-by: codex@openai.com

[andriiryzhkov]

Please describe the problem you are facing. What are the steps to reproduce it?

[andriiryzhkov]

Hey @sjuxax – same as #20774, there's been no movement here for a while, so I opened #20815 to port the part I could confidently review.

#20815 takes the decoder shape-array lifetime fix (iou_shape / lr_shape / low_res_shape moved out of the inner if(is_sam) block). That one is genuine UB per the C standard: pointers stored in outputs[] outlive the inner-scope arrays they point to, so dt_ai_run() reads dangling pointers. Zero-cost fix, and a latent time bomb for future compiler versions even if release builds don't trip on it today.

I left out the DT_AI_OPT_DISABLED workaround for the SAM2.1 encoder. My concern: it disables ORT graph optimization for every SAM2 user to work around an ORT 1.24.x UAF that, from the PR description, appears to have surfaced under ASan. Graph optimization on a transformer-heavy encoder like SAM2's hiera backbone isn't cheap to give up.

I looked for other evidence before porting and couldn't find any:

• ORT 1.24.x release notes (through 1.24.4) list several memory-safety fixes, but none mention constant folding or SAM2 session init.
• No matching issues in the upstream microsoft/onnxruntime tracker for SAM2 + 1.24.
• No matching reports in darktable's issue tracker or the pixls.us "Testing AI Object Masks" thread, despite SAM2 having been in nightly builds for a while.

We also already have a fallback chain in dt_ai_onnx_load_ext that retries with basic opt and then CPU if session creation throws. That would catch a cleanly-reported load failure, but wouldn't help if the UAF manifests as silent corruption or a hard crash.

A few questions that would help me understand:

• Does the UAF actually crash in a non-ASan release build, or is it only flagged under ASan instrumentation?
• Does it produce a catchable ORT error (and trip our retry fallback), or does it segfault / corrupt silently?
• Do you have a link to an upstream ORT issue, an ASan trace, or any other reports confirming this affects release builds?
• Would it make sense to gate the workaround on the ORT version reported by dt_ai_ort_probe_library_full(), so users on unaffected builds keep full optimization?

[andriiryzhkov]

This is too aggressive, results in performance regression for all