This repository was archived by the owner on Sep 6, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 6, 2023. It is now read-only.
Guru Meditation Error during socket.connect() #204
Description
If you try to socket.connect() to an unreachable TCP/IP address it eventually (~15 seconds) returns with
OSError: [Errno 113] EHOSTUNREACH
However, if you Ctrl-C during this time, the exception is immediately followed by a crash:
>>> s.connect(('10.107.1.6', 9999))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 113] EHOSTUNREACH
>>> NLR jump failed, val=0x3ffda814
Guru Meditation Error of type IllegalInstruction occurred on core 0. Exception was unhandled.
This occurs with network.WLAN() or the new network.LAN() adaptor.
Activity
nickzoic commentedon Oct 19, 2017
(yes, I'll have a look at this but I'm adding it here so I don't forget)
MrSurly commentedon Oct 19, 2017
Well, that explains recent problems I've had with WLAN.
Side Note, even
machine.reset()gives Guru Meditation (Ah, my Amiga days), so there's something weird with the current IDF being used.dpgeorge commentedon Oct 19, 2017
It looks like the ctrl-C that you press during connect() is being buffered. Then the EHOSTUNREACH exception is being raised, but the ctrl-C is still pending. The ctrl-C is then raised in some strange location which leads to the crash.
Apart from this being a bug (which may be difficult to track down the reason for), to fix connect() so that you can do ctrl-C to break out of it would require setting the socket to be non-blocking at the start, then do a loop polling for the connect() to complete. In that loop you can check for ctrl-C explicitly (by calling mp_handle_pending()).
Note: this stuff is already handled in esp8266 because it uses extmod/modlwip.c which wraps the lwIP stack at a lower level. And I don't think it's possible to hook into the esp32 lwIP stack at such a level, because it's probably not exposed and also there are multi-core issues to consider.
nickzoic commentedon Oct 19, 2017
Same behaviour in v1.9.2-279-g090b6b80
Similar in v1.9.2-225-g75ead22c (no "Guru" message, but same "NLR jump failed")
@dpgeorge yeah, I was thinking that, we do similar things elsewhere in that library to "fake" timeouts.
MrSurly commentedon Oct 19, 2017
All of the other socket stuff implements blocking/timeout with a loop, for this same reason. I think connect doesn't do this, because it doesn't seem LWIP allows you to set the connect timeout.
In
<IDF>/components/lwip/include/lwip/lwip/sockets.h... and it's not implemented in the API, either. =(
nickzoic commentedon Oct 19, 2017