Trapped local variable referenced before assignment in uasyncio. But it was assigned to.

[gmos]

Traceback (most recent call last):
  File "main.py", line 45, in <module>
  File "rmc/remcoo.py", line 94, in <module>
  File "uasyncio/core.py", line 177, in run_forever
  File "uasyncio/__init__.py", line 73, in wait
NameError: local variable referenced before assignment
MicroPython v1.12-184-gf8b2747 on 2020-02-20; ESP32 module (spiram) with ESP32

Code (uasyncio/__init__.py line 65 - 74)

    def wait(self, delay):
        if DEBUG and __debug__:
            log.debug("poll.wait(%d)", delay)
        # We need one-shot behavior (second arg of 1 to .poll())
        res = self.poller.ipoll(delay, 1)
        #log.debug("poll result: %s", res)
        # Remove "if res" workaround after
        # https://github.com/micropython/micropython/issues/2716 fixed.
        if res: 
            for sock, ev in res:

• The trap was located on line 73, which is the "if res:" statement.
  But "res" was assigned to, immediately before this statement.
• The bug is intermittent. There must have been 1000s calls of the wait method before this happened.
• uasyncio (only core is used) was precompiled and frozen from the .../esp32/modules directory.
• using a wrover with 16 MB flash.
• MicroPython commit 1fccda0
• This never has happened in the past. Seems to have started when I upgraded to the above version of MicroPython,

[andrewleech]

Which uasyncio module are you using, ie where did you source it from? There are a few different versions around.

[peterhinch]

Looks like official uasyncio V2.0 to me. It's not my version or Paul's.

[gmos]

Hi, it is the official one. Had it running stable for months continuously. When the errors started, I loaded a fresh one with upip. Then did a compare to the old one -> identical.

Don't think the errors are uasyncio related at all. Also did not change my application in the core. Main differences are that I upgraded MicroPython and the Espressif stuff (latest 3.x version with commit hash matching MicroPythons Makefile). I also started using LittleFS. Moreover, in the past I had wifi on in STA mode only. And I have recently added softAP on top of that.

I have been searching the net for similar errors, and https://loboris.eu/forum/showthread.php?tid=86&page=2 seems quite similar, albeit with an earlier version of the Loboris MP port.

I have seen the wait related error twice now, and whilst reading the aforementioned thread, I remembered that I also had seen: File "uasyncio/__init__.py", line ??
AttributeError: 'PollEventLoop' object has no attribute 'call_soon' once.

Since both erros cannot happen as Python errors: the local var is initialised and the call_soon method does exist, I think the issue is with stability of the MP or FreeRTOS.
And it is probably not a mistery that it emerges most often in the asyncio wait function, since this is what the application is doing most of the time: hanging in ipoll until time_out or very rarely an incoming socket connect and subsequent http request to the Picoweb server.

I could switch to the 4.x version of the Espressif code, but it is still flagged as experimental in the MP readme. So I'm a bit afraid overall stability will lessen.

[peterhinch]

I agree, I don't think this is uasyncio related.

I have seen "irrational" errors like this when RAM is low or fragmented. They are difficult to present as formal bug reports because they only happen with large programs and occur rarely. If you're running an ESP32 with SPIRAM RAM shortage would seem unlikely. Might there be a hardware issue?

[gmos]

Ample RAM available. Could be hardware. Using multiple boards. Unfortunately did not mark the one where I had the problems. I will wait for next occurrence and then try to reproduce with a small test program on that board and another one.

[dpgeorge]

It's hard to say exactly what the problem is here, but it does look like a (hardware) stability issue. It could be a problem with the SPIRAM because that is know to have "random" errors due to cache consistency.

I'd suggest to try with SPIRAM disabled.

[gmos]

Application cannot run with SPIRAM off. Waiting for next occurrence. And then I'll try to reproduce on that board with minimal application. Only after that I could try without SPIRAM.

[jonnor]

There is unfortunately not information here for a reproducible issue. Unless more details are given, issue will be closed.

[peterhinch]

This refers to uasyncio V2 which is long obsolete. Closing.