zephyr: Civetweb server crashing when trying to access invalid ressource
Describe the bug I tried to run the civetweb sample on the recommended target (Atmel SAM-E70 Xplained). Building and flashing seems to work fine. I’m using the Revision “B” of the Atmel-Chip, that i already figured out. Shortly after connecting to the webserver via browser, zephyr crashes. Before this, i flashed a bunch of basic samples without any issue.
To Reproduce Steps to reproduce the behavior:
- west build -b sam_e70b_xplained samples\net\civetweb\http_server
- west flash
- Call IP: 10.195.248.123:8080 in browser (changed IP to local range)
Expected behavior Zephyr not crashing 😃
Logs and console output
[00:00:00.000,000] <inf> i2c_sam_twihs: Device I2C_2 initialized
[00:00:00.000,000] <inf> i2c_sam_twihs: Device I2C_0 initialized
[00:00:00.001,000] <inf> eth_sam: MAC: fc:c2:3d:0c:2e:12
[00:00:00.001,000] <inf> eth_sam: Queue 0 activated
[00:00:00.001,000] <inf> eth_sam: Queue 1 set to idle
[00:00:00.001,000] <inf> eth_sam: Queue 2 set to idle
[00:00:00.001,000] <inf> eth_sam: Queue 3 set to idle
[00:00:00.001,000] <inf> eth_sam: Queue 4 set to idle
[00:00:00.001,000] <inf> eth_sam: Queue 5 set to idle
[00:00:00.001,000] <inf> eth_sam_phy: Soft Reset of ETH PHY
*** Booting Zephyr OS build zephyr-v2.5.0 ***
[00:00:00.091,000] <inf> eth_sam_phy: PHYID: 0x221561 at addr: 0
[00:00:00.095,000] <inf> net_config: Initializing network
[00:00:00.095,000] <inf> net_config: Waiting interface 1 (0x2040483c) to be up...
[00:00:03.122,000] <inf> eth_sam: Link up
[00:00:05.476,000] <inf> eth_sam_phy: common abilities: speed 100 Mb, full duplex
[00:00:05.476,000] <inf> net_config: Interface 1 (0x2040483c) coming up
[00:00:05.476,000] <inf> net_config: IPv4 address: 10.195.248.123
[00:00:05.477,000] <dbg> lib_extensions.sscanf: [IMPLEMENTATION MISSING : sscanf]
[00:01:54.926,000] <dbg> mg_cry_internal_impl.log_access: 10.195.248.121 - "GET /?null HTTP/1.1" 200
[00:01:54.987,000] <dbg> lib_extensions.strftime: [IMPLEMENTATION MISSING : strftime]
[00:01:54.987,000] <err> os: ***** USAGE FAULT *****
[00:01:54.987,000] <err> os: Illegal load of EXC_RETURN into PC
[00:01:54.987,000] <err> os: r0/a1: 0x00000000 r1/a2: 0x00400b29 r2/a3: 0x00000000
[00:01:54.987,000] <err> os: r3/a4: 0x00000000 r12/ip: 0x204072a8 r14/lr: 0x00000000
[00:01:54.987,000] <err> os: xpsr: 0x0040ee00
[00:01:54.987,000] <err> os: Faulting instruction address (r15/pc): 0x00000000
[00:01:54.987,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:01:54.987,000] <err> os: Current thread: 0x20404ef8 (unknown)
[00:01:55.062,000] <err> os: Halting system
Environment (please complete the following information):
- OS: Windows 10
- Toolchain: gnu arm embedded
- Zephyr Version: 2.5.0
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 17
Hey Lucas,
Thank you for your message. See my answers below.
Well here is important to know, if
DEBUGoption is enabled, cause as I mentioned previously not alllibcfunctionality is implemented in Zephyr today and civetweb expects some more libc functions, which will be compiled as stubs with -O3 e.g. DEBUG option enabled. Please check it. IFDEBUGoption is disabled Civetweb shouldn’t lead to MPU fault actually. Try to compilesamples/net/civetweb/websocket_server. sample.I think, we need to test it. I’ve already proposed updating Civetweb to the latest one (see it here). But I am not able to merge it. 😃 Please try to escalate it. I believe the more people interested in it, the mor chances we have to merge it.
I hope I could help you.
Thank you all very much for your very big effort in finding the bugs. I think with this knowledge the investigation of the bug can be done much faster. Unfortunately, I have no time for fix now. Sorry. I will take a look as soon as I can. If you are kind, you can always create your own fix. I can provide a review. I hope it is okay for you.
Another update: Thanks to @mglettig, i partially solved the issue. When connecting to the webserver via browser, there’s a GET request for an unimplemented resource called “favicon.ico”. When this request is blocked in the developer-options of the browser, zephyr does not crash!
The Output-Log seems fine now.
The zephyr-documentation for the civetweb-sample states, that a regular 404 error-code is returned then trying to access any unknown URL. It looks like this is not the case and should be fixed. Another approach would be to implement the corresponding resource. Please let me know if i misunderstood the issue.
Hi @Nukersson and thank you for your response.
I just tried the “dumb_http_server”-sample and this one worked just fine. I even connected multiple times to the webserver to ensure proper functionality.