Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% 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

While there are some other errors going on that also leave me scratching my head, the "expected error" happens on Windows CI, specifically "build-vs (x64, Debug, dev, 2017)".

Run python run-tests.py --print-failures
--- D:/a/micropython/micropython/tests/results\misc_sys_settrace_cov.py.exp	2025-06-20 18:41:30.413152600 +0000
+++ D:/a/micropython/micropython/tests/results\misc_sys_settrace_cov.py.out	2025-06-20 18:41:30.413152600 +0000
@@ -1,2 +1,2 @@
-FRAME <frame at 0x\[0-9a-f\]\+, file 'misc/sys_settrace_repr\.py', line \\d\+, code f>
-LASTI \\d\+
+FRAME <frame at 0xe06df4a0, file 'D:/a/micropython/micropython/tests/misc/sys_settrace_cov.py', line 20, code Assertion failed: *q < pool->len, file d:\a\micropython\micropython\py\qstr.c, line 198
+CRASH
\ No newline at end of file

FAILURE D:/a/micropython/micropython/tests/results\misc_sys_settrace_cov.py

I can't come up with any good theory as to what's making those unix builds fail. It's also a surprise that it's only ONE of the msvc x64 builds.

While working on extending sys.settrace() with additional capabilities I also noticed that the debug builds are not tested across ports. I first noticed Errors first popping up when building an ESP32 locally.

Is there a way to determine coverage locally?

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.23%. Comparing base (09541b7) to head (ec1036f).
Report is 20 commits behind head on master.

@@            Coverage Diff             @@
##           master   #17538      +/-   ##
==========================================
- Coverage   98.56%   98.23%   -0.34%     
==========================================
  Files         169      171       +2     
  Lines       21950    22142     +192     
==========================================
+ Hits        21636    21751     +115     
- Misses        314      391      +77     

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

Yes, you can go through the steps of the unix coverage build locally. In ports/unix, make VARIANT=coverage test_gcov. The build output will finish with a summary of coverage, and a large number of ".gcov" files will be written.

gcov files show coverage on a line by line basis, with "#####" indicating no coverage of the line, "-" indicating no coverage possible, and a number indicating the number of times the line was covered. The format is described in man gcov.

The nanbox build were failing like this:

-FRAME <frame at 0x\[0-9a-f\]\+, file '\.\*/sys_settrace_cov.py', line \\d\+, code f>
+FRAME <frame at 0xf4d622e0, file 'misc/sys_settrace_cov.py', line 16, code >

The reason is that a mp_uint_t is passed in to a %d format specifier. But in nanbox, sizeof(mp_uint_t) > sizeof(int), so again there's the UB problem that arises when the promoted argument type does not match the va_arg type.

This PR is now read only because it decreases the overall coverage percentage. In reality, it adds coverage to 21751 previously not covered lines.

I've updated the PR so that settrace is only enabled in the coverage build, not the standard build or other variants.

we should consider whether this makes the standard+settrace CI build redundant. I can remove that if desired. the standard+stackless+settrace CI job is probably still useful.

I've updated the PR so that settrace is only enabled in the coverage build, not the standard build or other variants.

Yes, that's a good idea. As mentioned, it really decreases performance.

OTOH, it's important to get coverage of the settrace code, so enabling it on the coverage build makes sense.

we should consider whether this makes the standard+settrace CI build redundant. I can remove that if desired. the standard+stackless+settrace CI job is probably still useful.

Yes, we can now simplify those CI jobs.

These settrace jobs were added in 0b85b5b . Maybe we can replace those two with just a test for stackless mode? Or at least just remove the standard+settrace CI and keep standard+stackless+settrace (as you suggest).

wrt the work on micropython-lib/python-ecosys/debugpy I have been contemplating a few changes as well

• moving the misc/sys_settrace*.* tests to their own folder: tests/sys_settrace
• there I have been updating and adding tests to cover the new functionality @andrewleech and I have been working on

That makes it simpler to run that subset during development.

• debug variant ?
  Also if you have guidance how to test the combination of a sys,settrace firmware together with micropython-lib/python-ecosys/debugpy that would be appreciated. Creating a separate 'settrace/debug' variant seems the simplest approach to me.