Skip to content

Hard fault crash when using HTTPServer:ESP32-C3 #9735

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dhalbert opened this issue Oct 20, 2024 · 7 comments
Closed

Hard fault crash when using HTTPServer:ESP32-C3 #9735

dhalbert opened this issue Oct 20, 2024 · 7 comments

Comments

@dhalbert
Copy link
Collaborator

dhalbert commented Oct 20, 2024

EDIT: closed in favor of #9749

Originally posted by @c--- in #9173 (comment)

Adafruit CircuitPython 9.2.0-beta.1 on 2024-10-11; Maker Go ESP32C3 Supermini with ESP32-C3

As far as I can tell, server.poll() might be the cause.

Currently using the following code.py that still crashes:

import wifi
import socketpool
from adafruit_httpserver import Server

pool = socketpool.SocketPool(wifi.radio)
server = Server(pool, debug=False)

while True:
   try:
      server.poll() 

   except Exception as e:
      print(str(e))
@jepler
Copy link

jepler commented Oct 20, 2024

Is this a duplicate of #9460 ?

@dhalbert
Copy link
Collaborator Author

Is this a duplicate of #9460 ?

It might be but it's a much simpler reproducer, which is great. We should try to fix this and then see ask @mMerlin if #9460 is fixed.

I consider this a showstopper for 9.2.0.

@dhalbert
Copy link
Collaborator Author

@c--- The test program above generates continuous ServerStopped exceptions. This is more easily seen if you do

while True:
   try:
      server.poll() 

   except Exception as e:
      print(type(e))

to print the type rather than the string form of the exception.

You do need a server.start(). However, in your original test program, you had:

server.start("0.0.0.0", 80)

If I add that, I do indeed get a hard crash. But instead of using 0.0.0., use this:

server.start(str(wifi.radio.ipv4_address))

In other words, for now, you need to specify the IP address specifically; "0.0.0.0" doesn't work. That's a bug we should fix.
You can also use server.serve_forever(...), which does the .start() and the .poll() loop for you.

@dhalbert dhalbert changed the title crash when using HTTPServer crash when using HTTPServer and 0.0.0.0 as IP address Oct 20, 2024
@mMerlin
Copy link

mMerlin commented Oct 21, 2024

What are the implications of this discovery for #9460 which was thought to be the same (or at least related) bug. That does not use the 0.0.0.0 address.

@dhalbert
Copy link
Collaborator Author

dhalbert commented Oct 21, 2024

What are the implications of this discovery for #9460 which was thought to be the same (or at least related) bug. That does not use the 0.0.0.0 address.

I don't think these are the same after all, after looking into it further.

@tannewt tannewt added the crash label Oct 21, 2024
@dhalbert dhalbert self-assigned this Oct 21, 2024
@dhalbert dhalbert changed the title crash when using HTTPServer and 0.0.0.0 as IP address Hard fault crash when using HTTPServer Oct 22, 2024
@dhalbert dhalbert changed the title Hard fault crash when using HTTPServer Hard fault crash when using HTTPServer:ESP32-C3 Oct 22, 2024
@dhalbert
Copy link
Collaborator Author

dhalbert commented Oct 22, 2024

Reproduced, but only on ESP32-C3. Test program:

import wifi
import socketpool
from adafruit_httpserver import Server
import time

time.sleep(5)
print("IP addr", wifi.radio.ipv4_address)

pool = socketpool.SocketPool(wifi.radio)
server = Server(pool, debug=False)

# port 80 will get EADDRINUSE due to web workflow
# Either IP adddress will cause a crash eventually.
server.start("0.0.0.0", 8000)
#server.start(str(wifi.radio.ipv4_address), 8000)

while True:
   try:
      server.poll()
   except Exception as e:
      print(type(e))

Either servert.start() can cause a crash: the wildcard IP address or the actual IP address don't matter. It takes around 1-5 minutes to restart in safe mode, though I have seen it run longer. No interaction with the HTTP server is needed. I simply restart code.py and wait.

I have reproduced this only on a QT Py ESP32-C3. I cannot reproduce on a QT ESP32-S3, with no PSRAM. I was hoping it might have been a storage leak.

@dhalbert
Copy link
Collaborator Author

I'm closing this in favor of #9749. There are several red herrings above, which are irrelevant to the actual issue.

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

No branches or pull requests

4 participants