Memory allocation remains after an exchange with the REPL via the serial port.

[jczic]

Hi, there is something strange about the memory reservation through the REPL via UART.

• MicroPython v1.19.1 on 2022-06-18
• ESP32C3 module
• IDF v4.4.1 with new lib 3.3.0

To reproduce my problem, you just have to connect serially to the REPL, copy/paste a lot of characters (either in the normal prompt, in RAW mode or copy/paste mode), for example a size of 15000, and then look at the memory allocated afterwards via gc.mem_alloc().

These characters seem to remain somewhere, even after a gc.collect().
Sometimes disconnecting the serial port and then reconnecting it empties this memory reservation, but more often than not, it remains and cannot be freed.
Also, a call to micropython.mem_info(1) show a real difference.

Is this a problem on my part or on the side of Micropython or IDF?
Maybe related to the logic of fragmentation blocks... I have no idea where this comes from.

[jczic]

Also, I have found 2 methods that together manage to clear the whole memory.

1. call : sys.stdin.read(0). ->. (empties only about half of the allocated memory...)
2. switch to another REPL mode (NORMAL/RAW..) and call gc.collect(). ->. (empties all the allocated memory)

Strange ?

[dpgeorge]

The memory is probably being used by the REPL history (when you press in recalls the last line). That's expected behaviour, because it needs to allocate memory to save the characters for the line. It has a history of 8 lines.

[jczic]

Indeed! But this, even in RAW mode?
Thank you @dpgeorge.

[dpgeorge]

Raw mode (and also REPL paste mode) still needs to allocate a buffer to hold the data, before it's executed. But that buffer can be freed once the compilation of the text is done.

Raw paste mode is different, it streams the data in as it compiles it.

[jczic]

Thank you and good luck with the code!