Skip to content

Commit d7c3f81

Browse files
committed
sharpdisplay: Fix memory corruption across soft-reset
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 micropython#2 0x0006ad6e in _refresh_display micropython#3 0x0006b168 in framebufferio_framebufferdisplay_background micropython#4 0x00069d22 in displayio_background micropython#5 0x00045496 in supervisor_background_tasks micropython#6 0x000446e8 in background_callback_run_all micropython#7 0x00045546 in supervisor_run_background_tasks_if_tick micropython#8 0x0005b042 in common_hal_neopixel_write micropython#9 0x00044c4c in clear_temp_status micropython#10 0x000497de in spi_flash_flush_keep_cache micropython#11 0x00049a66 in supervisor_external_flash_flush micropython#12 0x00044b22 in supervisor_flash_flush micropython#13 0x0004490e in filesystem_flush micropython#14 0x00043e18 in cleanup_after_vm micropython#15 0x0004414c in run_repl micropython#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: micropython#3473
1 parent 9e66c3a commit d7c3f81

File tree

1 file changed

+3
-5
lines changed

1 file changed

+3
-5
lines changed

shared-module/sharpdisplay/SharpMemoryFramebuffer.c

Lines changed: 3 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -90,10 +90,6 @@ bool common_hal_sharpdisplay_framebuffer_get_pixels_in_byte_share_row(sharpdispl
9090
}
9191

9292
void common_hal_sharpdisplay_framebuffer_reset(sharpdisplay_framebuffer_obj_t *self) {
93-
if (!allocation_from_ptr(self->bufinfo.buf)) {
94-
self->bufinfo.buf = NULL;
95-
}
96-
9793
if (self->bus != &self->inline_bus
9894
#if BOARD_SPI
9995
&& self->bus != common_hal_board_get_spi()
@@ -105,7 +101,9 @@ void common_hal_sharpdisplay_framebuffer_reset(sharpdisplay_framebuffer_obj_t *s
105101
}
106102

107103
void common_hal_sharpdisplay_framebuffer_reconstruct(sharpdisplay_framebuffer_obj_t *self) {
108-
104+
if (!allocation_from_ptr(self->bufinfo.buf)) {
105+
self->bufinfo.buf = NULL;
106+
}
109107
}
110108

111109
void common_hal_sharpdisplay_framebuffer_get_bufinfo(sharpdisplay_framebuffer_obj_t *self, mp_buffer_info_t *bufinfo) {

0 commit comments

Comments
 (0)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy