QUERY · ISSUE

gc_collect_root crash in VS2017 Release build

openby fei2020opened 2019-12-18updated 2019-12-18

I use upy 1.11. Running of Debug build works well. But Release one(VS2017 Release build with /O2) crash at gc.c LN343

void gc_collect_root(void **ptrs, size_t len) {
    for (size_t i = 0; i < len; i++) {
    .......
    }
}

CUE: Parameter "size_t len" get a very big value.
gc.c LN320

void gc_collect_start(void) {
    .......

    // Trace root pointers.  This relies on the root pointers being organised
    // correctly in the mp_state_ctx structure.  We scan nlr_top, dict_locals,
    // dict_globals, then the root pointer section of mp_state_vm.
    void **ptrs = (void**)(void*)&mp_state_ctx;
    size_t root_start = offsetof(mp_state_ctx_t, thread.dict_locals);
    size_t root_end = offsetof(mp_state_ctx_t, vm.qstr_last_chunk);
    gc_collect_root(ptrs + root_start / sizeof(void*), (root_end - root_start) / sizeof(void*));
    .......
}

some thing wrong at "(root_end - root_start) / sizeof(void*)"

CANDIDATE · PULL REQUEST

Gcdebugprintf

mergedby stinosopened 2026-02-04updated 2026-02-09

py-core

Summary

Debugging a possible gc issue with the msvc port I ran into a couple of issues:

there's no DEBUG_printf definition so enabling MICROPY_DEBUG_VERBOSE lead to a linker error
it seems as if a whole bunch of root pointers weren't being freed despite being unmarked, but that was simply because they were marked yet marking them was not logged

Testing

Compiles and the gc debug output is now complete.

Trade-offs and Alternatives

The last commit is more of an RFC: haven't used it enough to really assess its usefullness, on the other hand it shouldn't hurt either. Unless someone is relying on automated parsing of the output and looking for the literal gc_mark( string.