CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=fix_typo_spanish 2020-10-01T14:22:09+00:00 2020-10-01T14:22:09+00:00 Jeff Epler jepler@gmail.com 2020-10-01T14:21:39+00:00 urn:sha1:d7c3f811afd924bae8e0b009a4cfadd6fab29584 It was incorrect to NULL out the pointer to our heap allocated buffer in `reset`, because subsequent to framebuffer_reset, but while the heap was still active, we could call `get_bufinfo` again, leading to a fresh allocation on the heap that is about to be destroyed. Typical stack trace: ``` #1 0x0006c368 in sharpdisplay_framebuffer_get_bufinfo #2 0x0006ad6e in _refresh_display #3 0x0006b168 in framebufferio_framebufferdisplay_background #4 0x00069d22 in displayio_background #5 0x00045496 in supervisor_background_tasks #6 0x000446e8 in background_callback_run_all #7 0x00045546 in supervisor_run_background_tasks_if_tick #8 0x0005b042 in common_hal_neopixel_write #9 0x00044c4c in clear_temp_status #10 0x000497de in spi_flash_flush_keep_cache #11 0x00049a66 in supervisor_external_flash_flush #12 0x00044b22 in supervisor_flash_flush #13 0x0004490e in filesystem_flush #14 0x00043e18 in cleanup_after_vm #15 0x0004414c in run_repl #16 0x000441ce in main ``` When this happened -- which was inconsistent -- the display would keep some heap allocation across reset which is exactly what we need to avoid. NULLing the pointer in reconstruct follows what RGBMatrix does, and that code is a bit more battle-tested anyway. If I had a motivation for structuring the SharpMemory code differently, I can no longer recall it. Testing performed: Ran my complicated calculator program over multiple iterations without observing signs of heap corruption. Closes: #3473 2020-08-12T18:01:43+00:00 Jeff Epler jepler@gmail.com 2020-08-12T18:01:43+00:00 urn:sha1:195c0ea986fd44f3b56cc57f23e8259df1e18202 2020-08-12T12:32:18+00:00 Jeff Epler jepler@gmail.com 2020-08-06T21:03:31+00:00 urn:sha1:c1400bae9bbdd55f650ddfe24edf6778f08c35b8