fix(tracing): use-after-realloc in ddtrace_format_tracestate

[morrisonlevi]

Description

There is a logic error in ddtrace_format_tracestate that can theoretically result in a stale pointer read caused by a realloc.

I found this by investigating a customer crash which has smart_str_append in the stack. I am not sure it is this one.

Reviewer checklist

• Test coverage seems ok.
• Appropriate labels assigned.

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-05-12 01:18:27

Comparing candidate commit 4a8928f in PR branch codex/spanlink-long-origin-smart-str with baseline commit 7bb186d in branch master.

Found 0 performance improvements and 9 performance regressions! Performance is the same for 185 metrics, 0 unstable metrics.

scenario:PDOBench/benchPDOOverhead

• 🟥 execution_time [+6.249µs; +8.267µs] or [+2.528%; +3.344%]

scenario:PDOBench/benchPDOOverhead-opcache

• 🟥 execution_time [+8.009µs; +10.083µs] or [+3.262%; +4.106%]

scenario:PDOBench/benchPDOOverheadWithDBM

• 🟥 execution_time [+6.513µs; +8.725µs] or [+2.634%; +3.528%]

scenario:PDOBench/benchPDOOverheadWithDBM-opcache

• 🟥 execution_time [+6.466µs; +8.470µs] or [+2.625%; +3.439%]

scenario:PHPRedisBench/benchRedisOverhead-opcache

• 🟥 execution_time [+35.263µs; +49.320µs] or [+3.508%; +4.906%]

scenario:SamplingRuleMatchingBench/benchRegexMatching1-opcache

• 🟥 execution_time [+1.840µs; +2.173µs] or [+15.810%; +18.671%]

scenario:SamplingRuleMatchingBench/benchRegexMatching2-opcache

• 🟥 execution_time [+1.773µs; +2.050µs] or [+15.256%; +17.640%]

scenario:SamplingRuleMatchingBench/benchRegexMatching3-opcache

• 🟥 execution_time [+1.715µs; +1.987µs] or [+14.658%; +16.989%]

scenario:SamplingRuleMatchingBench/benchRegexMatching4-opcache

• 🟥 execution_time [+1.908µs; +2.192µs] or [+16.411%; +18.855%]