Skip to content

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

Description

@dhalbert

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

Activity

  1. added this to the 9.2.0 milestone on Oct 20, 2024
  2. jepler commented on Oct 20, 2024

    @jepler

    Is this a duplicate of #9460 ?

  3. dhalbert commented on Oct 20, 2024

    @dhalbert
    CollaboratorAuthor

    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.

  4. dhalbert commented on Oct 20, 2024

    @dhalbert
    CollaboratorAuthor

    @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.

  5. changed the title [-]crash when using HTTPServer[/-] [+]crash when using HTTPServer and 0.0.0.0 as IP address[/+] on Oct 20, 2024
  6. mMerlin commented on Oct 21, 2024

    @mMerlin

    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.

  7. dhalbert commented on Oct 21, 2024

    @dhalbert
    CollaboratorAuthor

    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.

  8. self-assigned this
    on Oct 21, 2024
  9. changed the title [-]crash when using HTTPServer and 0.0.0.0 as IP address[/-] [+]Hard fault crash when using HTTPServer[/+] on Oct 22, 2024
  10. changed the title [-]Hard fault crash when using HTTPServer[/-] [+]Hard fault crash when using HTTPServer:ESP32-C3[/+] on Oct 22, 2024
  11. dhalbert commented on Oct 22, 2024

    @dhalbert
    CollaboratorAuthor

    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.

  12. dhalbert commented on Oct 23, 2024

    @dhalbert
    CollaboratorAuthor

    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

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions