Skip to content
This repository has been archived by the owner on Sep 6, 2023. It is now read-only.

Guru Meditation Error during socket.connect() #204

Open
nickzoic opened this issue Oct 19, 2017 · 6 comments
Open

Guru Meditation Error during socket.connect() #204

nickzoic opened this issue Oct 19, 2017 · 6 comments

Comments

@nickzoic
Copy link
Collaborator

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.

@nickzoic
Copy link
Collaborator Author

(yes, I'll have a look at this but I'm adding it here so I don't forget)

@MrSurly
Copy link
Contributor

MrSurly commented 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
Copy link
Member

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
Copy link
Collaborator Author

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
Copy link
Contributor

MrSurly commented Oct 19, 2017

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()).

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

#define SO_CONTIMEO    0x1009 /* Unimplemented: connect timeout */

... and it's not implemented in the API, either. =(

@nickzoic
Copy link
Collaborator Author

nickzoic commented Oct 19, 2017 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants