Exception when a socket is closed

[nkolban]

User @jumjum123 reported a problem in the gitter stream that has been able to be trivially recreated. He supplied an awesome demonstration video here.

http://jumspruino.jumware.com/problems/Problem_one.mp4

The symptom is that if one sets up a Web Server which has a bad JS statement in the processing of a URL request and then one connects a browser ... and THEN one closes the waiting socket connection, the ESP8266 asserts. Examining UART1 ... we find a clear exception message:

> net_ESP8266_BOARD_closeSocket, socket=1
Dump of espconn: 0x3fffa808
 - type = TCP
Fatal exception 28(LoadProhibitedCause):
epc1=0x4022b417, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000004, depc=0x00000000

Which seems to show bad memory access during the socket close. Next steps are to drill down on this in detail and see what is going on.

[nkolban]

The nature of this problems was very interesting and deserves a write up. Within the ESP8266 there is a data structure called an "espconn" that is allocated by the programmer and serves as the control block for sockets. There is one exception to this ... and that is when an incoming socket request arrives from a client and the ESP8266 itself allocates the "espconn". Because the ESP8266 has allocated the espconn, it is responsible for discarding it when no longer needed. Since we save a reference to our espconn in our sockets structure, if the ESP8266 has discarded the old espconn structure (presumably through an os_free()), then we can't reference inside its content any more. This shouldn't be a problem as the time at when the espconn is discarded by the ESP8266 happens is when we receive a disconnect callback ... we shouldn't need to look inside the data any further.

However, since we have an Espruino model of a socket and an actual network connection, when the actual network connection is dropped, we flag the socket as closing. Eventually, Espruino will call the Espruino model level "closeSocket" ... and in there ... in a debug statement ... we dump the "espconn" structure ... but wait ... for connections that were created by incoming client connections, the data is no longer valid ... and we shouldn't look inside. The solution was trivial ... don't debug ESPCONN data structures when closing sockets.

[nkolban]

Fix delivered in #623.