Closed martijnthe closed 5 years ago
Hi @martijnthe , I acknowledge the issue you pointed out, the problem was that the memory allocated for the lock creation was not taken from GC memory pool rather it was allocated from independent RAM area, where GC had no control over. that's why gc_collect
had no effect in the code above.
Also the reason you see the free heap size in response of machine.info
not affected is that because the displayed heap is of a different Heap space that had no memory allocated for locks.
Is this resolved in the development branch?
It is resolved in new release candidate that will be released this week.
(sysname='LoPy', nodename='LoPy', release='1.18.1.r1', version='f5d0c68 on 2018-09-06', machine='LoPy with ESP32', lorawan='1.0.2')
-- custom build but very close to1.18.1.r1
.It seems like locks that are created using
_thread.allocate_lock()
do not get free'd properly (or perhaps I don't understand micropyton's memory management model?).See below for a little experiment that will end up triggering an
MemoryError: can't create lock
exception. From that point on the wifi stack also stops working, see https://github.com/pycom/pycom-micropython-sigfox/issues/218According to
machine.info()
there's plenty of free heap space, but I guess the locks are allocated on a different heap (it would be nice to be able to show stats about that heap as well...)How can I get rid of these leaky locks?