pycom / pycom-micropython-sigfox

A fork of MicroPython with the ESP32 port customized to run on Pycom's IoT multi-network modules.
MIT License
199 stars 167 forks source link

_thread lock not being free'd properly? #219

Closed martijnthe closed 5 years ago

martijnthe commented 5 years ago

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/218

According 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?

>>> import gc
>>> from _thread import allocate_lock
>>> for idx in range(0, 2000):
...     l = allocate_lock()
...     del l
...     if idx % 10 == 0:
...         gc.collect()
...
...
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
MemoryError: can't create lock

>>> import machine
>>> machine.info()
---------------------------------------------
System memory info (in bytes)
---------------------------------------------
MPTask stack water mark: 3564
ServersTask stack water mark: 1448
LoRaTask stack water mark: 1700
TimerTask stack water mark: 1940
IdleTask stack water mark: 576
System free heap: 258160
---------------------------------------------
iwahdan88 commented 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.

Sympatron commented 5 years ago

Is this resolved in the development branch?

iwahdan88 commented 5 years ago

It is resolved in new release candidate that will be released this week.