kopia lustrzana https://github.com/micropython/micropython
py/parse: Zero out dangling parse tree pointer to fix potential GC leak.
This fixes a bug where a random Python object may become un-garbage-collectable until an enclosing Python file (compiled on device) finishes executing. Details: The mp_parse_tree_t structure is stored on the stack in top-level functions such as parse_compile_execute() in pyexec.c (and others). Although it quickly falls out of scope in these functions, it is usually still in the current stack frame when the compiled code executes. (Compiler dependent, but usually it's one stack push per function.) This means if any Python object happens to allocate at the same address as the (freed) root parse tree chunk, it's un-garbage-collectable as there's a (dangling) pointer up the stack referencing this same address. As reported by @GitHubsSilverBullet here: https://github.com/orgs/micropython/discussions/14116#discussioncomment-8837214 This work was funded through GitHub Sponsors. Signed-off-by: Angus Gratton <angus@redyak.com.au>pull/14136/head
rodzic
9d27183bde
commit
71044a4186
|
@ -1386,6 +1386,7 @@ void mp_parse_tree_clear(mp_parse_tree_t *tree) {
|
||||||
m_del(byte, chunk, sizeof(mp_parse_chunk_t) + chunk->alloc);
|
m_del(byte, chunk, sizeof(mp_parse_chunk_t) + chunk->alloc);
|
||||||
chunk = next;
|
chunk = next;
|
||||||
}
|
}
|
||||||
|
tree->chunk = NULL; // Avoid dangling pointer that may live on stack
|
||||||
}
|
}
|
||||||
|
|
||||||
#endif // MICROPY_ENABLE_COMPILER
|
#endif // MICROPY_ENABLE_COMPILER
|
||||||
|
|
Ładowanie…
Reference in New Issue