* gh-152721: Fix quadratic RLE replay time in the profiling binary reader
* gh-152721: Clarify the batch-list comment
Reword per review: the list is built with append per element, not
pre-sized; note the old alloc(count - i) + trim per batch was O(count^2).
* Cap RLE batch size to bound the per-batch timestamp list
* Move MAX_RLE_BATCH_SAMPLES comment to its own line (keep under 79 cols)
* Drop the now-redundant emit_batch trim and fix the review nits
The batch list is built to its exact size, so the PyList_SetSlice trim was a no-op; call emit_sample directly. Also point the cap comment at the issue (gh-151378) and drop the stale over-long comment.
* gh-152721: Test replay batches beyond the RLE limit
---------
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
* Run the test suite with MSan in CI
* Additional fixes
* Add `_Py_MSAN_UNPOISON_STRING`
* Apply Victor's suggestions
Co-authored-by: Victor Stinner <victor.stinner@gmail.com>
* Apply Victor's suggestions
Co-authored-by: Victor Stinner <victor.stinner@gmail.com>
---------
Co-authored-by: Victor Stinner <victor.stinner@gmail.com>
Compute ``final_depth`` in ``decode_stack_pop_push()`` and
``decode_stack_suffix()`` using ``uint64_t`` before validating it.
On 32-bit builds, using ``size_t`` arithmetic for ``keep + push`` can wrap
for large input values, causing the later bounds check to validate the wrong
final depth. Using a widened type keeps the validation aligned with the
actual result.
