The function __txn_resolve_prepared_update_chain in src/txn/txn.c (line 1076) was implemented using recursion to traverse key update chains in oldest-first order during prepared transaction commits or rollbacks. For transactions with a deep update chain on a single key (e.g., thousands of updates to the same row-store key), this recursive approach allocates N concurrent stack frames, causing a stack overflow (SIGSEGV).

For Reproduce;
Added a regression unit test wt<this wt number(I added the WT number later, after this issue was opened>_prepared_deep_chain in test/csuite that spawns a thread with a restricted stack size of 512KB and drives 5,000 updates to the same key. This test reproduces the stack overflow on the unfixed code and confirms the iterative resolver completes successfully without overflowing the stack once the fix is applied. (I added before/after outputs on JIRA)

Purposed fix;
To solve this, replaced the recursive logic with an iterative approach that counts the active prepared updates and allocates a temporary pointer array using WiredTiger's session-level scratch buffer pool (__wt_scr_alloc). The updates are then resolved in reverse order (oldest-first) using this array, which preserves the original visibility invariants, keeps memory allocation overhead at zero in the common path, and ensures that only one update is in the WT_PREPARE_LOCKED state at any single moment.