Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.44%. Comparing base (df05cae) to head (d1ff01d).

@@           Coverage Diff           @@
##           master   #17649   +/-   ##
=======================================
  Coverage   98.44%   98.44%           
=======================================
  Files         171      171           
  Lines       22192    22192           
=======================================
  Hits        21847    21847           
  Misses        345      345           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:   +16 +0.002% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Thanks for the patch.

Can you describe a test which shows that this is necessary? The CI has been passing, and it does recursive depth tests, so I wonder why it's needed.

I'm not very confident I understand what's going on here, as I've not been able to figure out how to successfully link a clang build of micropython with the asan and ubsan sanitizers in question on linux, but after digging in on what the stack check margin actually does...

the compiler enlarges each C call frame; MicroPython’s stack-overflow guard can therefore trigger before the real end of the stack.

This is actually the opposite of what I believe is happening. Setting MICROPY_STACK_CHECK_MARGIN to a larger value makes micropython's stack-checking more paranoid, i.e. larger values make it trigger earlier, while the stack is still smaller.

inline static void mp_cstack_init_with_top(void *top, size_t stack_size) {
    MP_STATE_THREAD(stack_top) = (char *)top;

    #if MICROPY_STACK_CHECK
    assert(stack_size > MICROPY_STACK_CHECK_MARGIN); // Should be enforced by port
    MP_STATE_THREAD(stack_limit) = stack_size - MICROPY_STACK_CHECK_MARGIN;
    #else
    (void)stack_size;
    #endif
}

void mp_cstack_check(void) {
    if (mp_cstack_usage() >= MP_STATE_THREAD(stack_limit)) {
        mp_raise_recursion_depth();
    }
}

MP_NORETURN void mp_raise_recursion_depth(void) {
    mp_raise_type_arg(&mp_type_RuntimeError, MP_OBJ_NEW_QSTR(MP_QSTR_maximum_space_recursion_space_depth_space_exceeded));
}

Which then leaves margin for C functions called between the stack checks to use up to 8192 bytes more than the specified stack limit, before those operations actually start to overrun --- i.e. converting a situation that might result in a hard stack overflow, or memory corruption on platforms without stack guard pages and the like.

But that still leaves an unanswered question:
What is is micropython actually doing that would convince a sanitizer that some of its stack accesses are out-of-bounds?

@dpgeorge @AJMansfield @projectgus
Thank you for reviewing this PR.
During the last two days I fixed some bugs and added tests on the t‑strings branch. After this work my view on this patch changed.
Now t‑strings is enabled only on ports with a larger stack (macOS, WebAssembly, Windows, etc.). In these builds the tests pass without changing MICROPY_STACK_CHECK_MARGIN, so the PR looks unnecessary.
But when I made a test with many interpolations, I still got a stack‑overflow in a sanitizer build. On smaller targets we avoid this by disabling the feature, but it might point to a hidden issue between sanitizer builds and our stack checker.
Should I keep improving this PR based on the review, or should we close it because we don’t need it now?
Feedback from people who often run sanitizer builds would be very helpful.

@koxudaxi Appreciate the update, thanks. I think that until someone encounters this problem again then we should close this, but keep this PR in mind if they do run into stack issues when using sanitizers. (Others may recommend differently, though.)