MicroPython Forum (Archive)

Dear all Thank you so much for clearing this up. After investigating, I found that another object outside of the heap area that I was investigating was being garbage collected. I had thought that the API was keeping a copy of this memory, but it was in fact keeping a typecast pointer to the old stri...

Thanks all So we can confirm that the GC shouldn't touch memory which is created by the platform's own malloc (e.g. ESP32 heap_caps_malloc). I am getting an issue with this memory becoming corrupted after GC sweeps, and I presume there's something 'indirect' going on. My next step is to trace down h...

hi all i see the same issue with uint8_t heapAreaGlobal[2 * 1024 + alignment]; i.e. when memory is defined statically at the top of the cpp file, it is still (somehow) affected by the garbage collector let me explain what happens: 1. Allocate a section of memory to store tensors, objects, models, et...

I'm still having issues with memory that's allocated with malloc

From the other comments, it sounds like memory allocated using the standard functions (e.g. new and malloc) can still be affected. Is this true?

Ok looking at the source code more, it looks like memory allocated in the standard ways (e.g. malloc) shouldn't be affected by the garbage collector (the gc uses a malloc at the start of run to make its own block of memory 'the heap')

investigating..

Ok here's where I'm at: tensorflow asks for a chunk of memory that it can use: const int tensor_arena_size = 2 * 1024; uint8_t tensor_arena[tensor_arena_size]; It then uses this memory to store everything (both the model and the variables) On garbage collection, this pointer is generally invalidated...

Oh this is really interesting. I'm having issues here with my allocated memory becoming invalid after garbage collection. I have code classes in C++ being exported across to C I have read up on garbage collection before, but I'm unaware of the strategy of scanning the heap for pointers. It seems str...

It happened once more today. The sequence was - make clean - make - make USER_C_MODULES=../../modules This mirrors my experience before It fails on the 3rd step. So I presume it fails to detect a change in the QSTR here If it's sporadic, then maybe we should just add a line to the documentation for ...

Update :
I have got it working now (in a round-about-hacky way)
Notes in the github issue above

Thank you all!

I've also made a request on the GitHub for official support for CPP in user modules:
https://github.com/micropython/micropython/issues/6233

Maybe it's best that I continue this conversation over there instead