GC auto or not?

[kjm]

We continue to play whack-a-mole with GPY lte connection stability. As we eliminate problems we are left with more obscure errors (eg OSError: [Errno -29312] MBEDTLS_ERR_SSL_CONN_EOF). The only thing they have in common when googled is the suggestion to import gc; gc.collect() Is this what people do when they can't think of anything better to do? I thought garbage collection was supposed to be automatic? Should I simply run gc permanently on a loop in a separate thread?

[andreas]

Dear @kjm,

@kjm said in GC auto or not?:

We continue to play whack-a-mole with GPY lte connection stability. As we eliminate problems we are left with more obscure errors (eg OSError: [Errno -29312] MBEDTLS_ERR_SSL_CONN_EOF).

These resources might give you some clues:

• https://github.com/espressif/esp-idf/issues/1009
• https://github.com/espressif/esp-idf/issues/3624
• https://github.com/espressif/esp-idf/issues/4127

I am really encouraging you to give the Dragonfly firmware [1] a try as it already fixes some of the problems outlined within those issues, especially the PSRAM bug.

With kind regards,
Andreas.

[1] https://community.hiveeyes.org/t/dragonfly-firmware-for-pycom-esp32/2746

[kjm]

tnx, do you know what the 'ho 0 tail 12 room 4' gpy reboot message means?

[crumble]

GC cost time and power. This implementation cannot fix fragmentation, so it depends on your problem, In the case of fragmentation, it may not be helpful in any states. So it is better to redesign your program, so that it will not allocate huge blocks over the whole runtime.

Calling the GC takes time. If people were lucky, this may have fixed timing, synchronization and memory sccess problems in the past. Since IDF 3.2 a lot of them are fixed, So it may not be the multi tool for strange issues any longer ;)