ESP32-S3 Ctrl-D caused hard crash after get message is sent to adafruit_requests object unless _free_sockets() is called #6502
Comments
|
I downloaded 7.3.1 from circuitpython.org and this still seems to occur on both the Devkit and FeatherS3 boards. I built an 8.0.0 FeatherS3 CP from the master Github bits and the issue still occurs, however when I build 8.0.0 from the master for the Devkit the problem seems to have gone away. |
|
On a hunch, I threw a .env file on the FeatherS3 running 8.0.0 and the crash no longer occurs when pressing ctrl-D. So apparently adding the wifi SSID and password via the .env prevents this crash from occurring. |
|
The output of the debug console from the crash: |
|
From Espressif api-guides: LoadProhibited, These CPU exceptions happen when an application attempts to read from an invalid memory location. The address which has been read is found in the EXCVADDR register in the register dump. If this address is close to zero, it usually means that the application has attempted to access a member of a structure, but the pointer to the structure is NULL. |
|
Okay, so after looping back and looking at the https._free_sockets() module I realized that the proper way for the function to be called would be to use the response.close() method and adding that statement does prevent the crash which is at least a better option than calling the private _free_sockets() method. |
|
I can't reproduce this, but I'm not sure if I followed the steps as you intended. wifi is set up via wifi workflow. I repeated the above a couplle of times and never got a hard fault. |
|
I have a UM FeatherS3, QT Py S3, and Adafruit Feather S3. Is the devkit S3 specifically needed for this test or would one of the boards I have be ok? Also what version of CP should I test this with? Is this a custom build that only OP can test since some are dirty? |
|
@DJDevon3 You should be able to reproduce this on any of the S3 boards although I've only tested a few. @jepler You do have to rename the .env file so the web workflow doesn't load. I've tested using both the old secrets file and manually typing the ssid/password into the wifi.radio.connect call on the following. (I can dig out more S3 boards if we need a bigger sample) Adafruit CircuitPython 8.0.0-beta.4-35-gf637332de-dirty on 2022-11-18; FeatherS3 with ESP32S3 The DevKitC got stuck in a boot loop somehow using the alpha.1 code so I reflashed with the latest nightly and also reproduced the crash to safe mode Adafruit CircuitPython 8.0.0-beta.4-57-ge82a8bf8b on 2022-11-30; ESP32-S3-DevKitC-1-N8R2 with ESP32S3 |
Bug ConfirmedLikely related to 6791 first reported in August and by many others since then (keep an eye out for duplicate reports to merge) import ssl
import wifi
import socketpool
import adafruit_requests as requests
from secrets import secrets
wifi.radio.connect(secrets["ssid"], secrets["password"])
socket = socketpool.SocketPool(wifi.radio)
https = requests.Session(socket, ssl.create_default_context())
TEXT_URL = "https://finance.yahoo.com/quote/%5EIXIC"
response = https.get(TEXT_URL)
print(response)
print("finished")
<Response object at 0x3de0c450>
finished
Code done running.
Auto-reload is off.
Running in safe mode! Not running saved code.
(board unresponsive, reloaded serial terminal)
You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Crash into the HardFault_Handler.
Please file an issue with the contents of your CIRCUITPY drive at
https://github.com/adafruit/circuitpython/issues
Press any key to enter the REPL. Use CTRL-D to reload.Serial locks up, looks like some kind of hard reset bug. Hard reset works once. There's no errors just a freeze. Mu will save the file no problem but it doesn't trigger a reload. Ctrl+C/Ctrl+D unresponsive.
Auto-reload is off.
Running in safe mode! Not running saved code.
You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Crash into the HardFault_Handler.
Please file an issue with the contents of your CIRCUITPY drive at
https://github.com/adafruit/circuitpython/issues
Press any key to enter the REPL. Use CTRL-D to reload.The QT Py S3 did one reload on save, didn't even get to the print statements and crashed. Board disconnected from USB and reloaded in safemode, hard fault crash. At one point, maybe in 7.3.3, I reported that the QT Py S3 wasn't affected by this bug. I just updated the Qt Py to latest nightly and it is now affected by it.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
<Response object at 0x3d830170>
finished
Code done running.
--Board unresponsive, closed and reopened serial to this
You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Crash into the HardFault_Handler.
Please file an issue with the contents of your CIRCUITPY drive at
https://github.com/adafruit/circuitpython/issues
Press any key to enter the REPL. Use CTRL-D to reload.UM Feather S3 identical result as Adafruit Feather ESP32-S3. Disconnected/Reconnected USB, ctrl+c/ctrl+d unresponsive. Board frozen. Attempting to save file in Mu says it's saving but board seems unresponsive. Reloaded serial to find a hard fault message. This happens (with the above script) on the 3 different S3's. I have not attempted to use response.close() which is a really nice workaround if true and perhaps we're all using the wrong methodology in using wifi if it's required? Still having an error message is better than a hard fault, hard fault is still a bug. |
|
I ran again with web workflow NOT enabled and confirmed the issue. |
|
I've traced the location of the crash into The pointers are ... both seem to be inside the gc heap. |
A crash would occur if an SSL socket was not shut down before `gc_deinit()`. I do not fully understand the root cause, but some object deinitialization / deallocation prior to `gc_deinit` leaves the SSL object in an inconsistent state. Rather than resolve the root cause, instead ensure that the closing of the user socket also closes the SSL socket. Closes: adafruit#6502
|
This makes a lot of sense since others have reported it has a random memory leak like behavior and gc has no effect on it, even if gc is explicitly used manually. |
CircuitPython version
Code/REPL
Behavior
The code runs fine, you can even continue to use the response object, the following instruction will print the next 32 bytes of the stream:
but after the .get message has been sent, unless
https._free_sockets()is called, the next Ctrl-D causes the board to crash into safe mode. On the Devkit, the following is displayed over the UART connection:Description
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: