Kernel Panic serving anything if local MicroDNSSrv used #25

UnexpectedMaker · 2020-03-01T06:57:36Z

Make sure you are running the latest version of TinyWeb before reporting an issue.

Device and/or platform:

MicroPython, TinyPICO (ESP32) (latest - built from source today)
Built against IDF 4.0 release
Using latest MicroDNSSrv for DNS + latest TinyWeb for Webserver.

Description of problem:

Webserver is running as expected if I connect to my wifi and run the server with the host set to my IP given by the DNS.

But my use case is to set local DNS and start an AP and connect to my AP, and have it serve pages from that - Making a MicroPython WifiManager-esq system for my application.

If I set the DNS to be MicroDNSSrv using this...

dns = MicroDNSSrv.Create({ '*' : '192.168.4.1' })

And connect to it, as soon as it tries to serve the / page, I get a kernel panic!

Expected:

It should just serve me the page. Even the most basic of pages kernel panics. There should never be a kernel panic from a module.

This setup works with MicroWebServ2 as the web server, and my basic sockets based web server. I moved to TinyWeb as I need an uasyncio based web server as I'm transitioning the rest of my app to be asyncio based.

Error:

`>>> import tw
I (110680) phy: phy_version: 4180, cb3948e, Sep 12 2019, 16:39:13, 0, 0

tw.run()
Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1)
Core 1 register dump:
PC : 0x40093c30 PS : 0x00060034 A0 : 0x80096544 A1 : 0x3ffbb150
A2 : 0x3ffba694 A3 : 0x3f427d11 A4 : 0x3ffba6a8 A5 : 0x3ffbeaf0
A6 : 0x3ffbeb38 A7 : 0x00000001 A8 : 0x00000000 A9 : 0x00000000
A10 : 0x00000000 A11 : 0x00000011 A12 : 0x8009707b A13 : 0x3ffbeac0
A14 : 0x00000020 A15 : 0x00000020 SAR : 0x00000018 EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000 LBEG : 0x400948e0 LEND : 0x4009490e LCOUNT : 0x00000000
ELF file SHA256: `

Traceback (if applicable):

Additional info:

Please let me know if there is anything else I can provide!

Code:

import tinyweb, network
from microDNSSrv import MicroDNSSrv

wlan_ap = network.WLAN(network.AP_IF)
wlan_ap.active(True)
wlan_ap.config(essid='Seon')

dns = MicroDNSSrv.Create({ '*' : '192.168.4.1' })

# sta = network.WLAN(network.STA_IF)
# sta.active(True)
# sta.connect('aaa', 'bbb')
# sta.ifconfig()

# Create web server application
app = tinyweb.webserver()


# Index page
@app.route('/')
async def index(request, response):
    # Start HTTP response with content-type text/html
    await response.start_html()
    # Send actual HTML page
    await response.send('<html><body><h1>Hello, world! (<a href="/table">table</a>)</h1></html>\n')


# Another one, more complicated page
@app.route('/table')
async def table(request, response):
    # Start HTTP response with content-type text/html
    await response.start_html()
    await response.send('<html><body><h1>Simple table</h1>'
                        '<table border=1 width=400>'
                        '<tr><td>Name</td><td>Some Value</td></tr>')
    for i in range(10):
        await response.send('<tr><td>Name{}</td><td>Value{}</td></tr>'.format(i, i))
    await response.send('</table>'
                        '</html>')


def run():
    app.run()

The text was updated successfully, but these errors were encountered:

tve · 2020-03-01T07:37:05Z

After the guru meditation error, do you get a backtrace line with lots of addresses? That would be helpful.
I just built from master and the crash location seems to be PC: 0x40093c30 is in coex_bt_high_prio (bt_bb.c:395). But that assumes I build exactly the same you did...
Ideally... you build using DEBUG=1 option to make. Then, when you get that guru meditation error, you run the backtrace script from https://github.com/tve/esp32-backtrace with build-TINYPICO/application.elf as arg and paste the whole shebang in (the git repo has an example). That will tell you/others what the call stack was at the point of crashing...

UnexpectedMaker · 2020-03-01T07:52:58Z

After the guru meditation error, do you get a backtrace line with lots of addresses? That would be helpful.
I just built from master and the crash location seems to be PC: 0x40093c30 is in coex_bt_high_prio (bt_bb.c:395). But that assumes I build exactly the same you did...
Ideally... you build using DEBUG=1 option to make. Then, when you get that guru meditation error, you run the backtrace script from https://github.com/tve/esp32-backtrace with build-TINYPICO/application.elf as arg and paste the whole shebang in (the git repo has an example). That will tell you/others what the call stack was at the point of crashing...

Hey @tve :)
No backtrace - That's the entire output.
I'll re-build the firmware now with DEBUG=1 and see if I can get a backtrace.. hold the phone!

UnexpectedMaker · 2020-03-01T08:12:20Z

If I set DEBUG=1 when I call make, I get no panic, but it also doesn't work. No web page is served. If I rebuild without DEBUG=1, it panics again.

Also, if I need to run that esp32-backtrace on the session after it panic'd, that's not possible as the device is completely locked up. Have to hard-reset it.

tve · 2020-03-01T08:14:40Z

you run the esp32-backtrace on your laptop and paste the backtrace output into it (stdin).

UnexpectedMaker · 2020-03-01T08:32:23Z

Ok, well I can't seem to get a backtrace at all.
Just did the loop again, with no DEBUG=1, I get that panic, but no call stack.
With DEBUG=1, I can kinda get it working... not quite how I want, but no panics.

So what does BEDUG=1 do? I'm going to post this extra nugget on the MP github issue I raised.

tve · 2020-03-01T16:40:36Z

Oh, I didn't read carefully enough... the error is "Interrupt wdt timeout on CPU1" that means the watchdog triggered, so the backtrace is irrelevant.

dpgeorge · 2020-03-03T01:33:39Z

@UnexpectedMaker it sounds like this is related to threading and could be a deadlock if the WDT is triggering.

Does it crash using IDF v3? Does it crash when using the STA interface only and connecting to a local network (and still running MicroDNSSrv)? Or is the problem only when the ESP32 acts as an AP?

UnexpectedMaker · 2020-03-03T02:11:18Z

Hi @dpgeorge - I've not tried all of those combinations, as I only need DNS for when I am using the AP, and all of my projects are now on IDF4 only.

I do know it works fine without the DNS with STA. If I find some time, I'll try to test it out against IDF3.

It's curious that it works fine when DEBUG=1 is set, though I don't really know what changes when DEBUG is on.

UnexpectedMaker mentioned this issue Mar 1, 2020

I have a Kernel Panic situation using a combo of TinyWeb + MicroDNSSrv micropython/micropython#5712

Open

This was referenced Mar 16, 2020

No CaptivePortal support? #26

Closed

Still can't get captive portals working :( #27

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Kernel Panic serving anything if local MicroDNSSrv used #25

Kernel Panic serving anything if local MicroDNSSrv used #25

UnexpectedMaker commented Mar 1, 2020 •

edited

Loading

tve commented Mar 1, 2020

UnexpectedMaker commented Mar 1, 2020

UnexpectedMaker commented Mar 1, 2020

tve commented Mar 1, 2020

UnexpectedMaker commented Mar 1, 2020

tve commented Mar 1, 2020

dpgeorge commented Mar 3, 2020

UnexpectedMaker commented Mar 3, 2020

Kernel Panic serving anything if local MicroDNSSrv used #25

Kernel Panic serving anything if local MicroDNSSrv used #25

Comments

UnexpectedMaker commented Mar 1, 2020 • edited Loading

tve commented Mar 1, 2020

UnexpectedMaker commented Mar 1, 2020

UnexpectedMaker commented Mar 1, 2020

tve commented Mar 1, 2020

UnexpectedMaker commented Mar 1, 2020

tve commented Mar 1, 2020

dpgeorge commented Mar 3, 2020

UnexpectedMaker commented Mar 3, 2020

UnexpectedMaker commented Mar 1, 2020 •

edited

Loading