https://toitlang.org/ logo
Powered by
Guru Meditation Error
# help
r
what is it? I am letting Jaguar run a container that deepsleeps and I experiance all kinds of failures.
f
Can you share the output you are seeing?
Guru meditation errors are crashes in the system.
Normally you should never see these.
Which chip (esp32, esp32s3, ...) are you using? Which version of Jaguar? (
jag version
). Can you share a reproducible test-case? (but maybe share the full output first, before you spend resources creating the repro).
r
using version jag 1.41.0 on 3 yr old ESP32 - revision 3.0. Part of the output:
time to sleep Guru Meditation Error: Core 0 panic'ed (InstrFetchProhibited). Exception was unhandled. Core 0 register dump: PC : 0x00000000 PS : 0x00060430 A0 : 0x8011f1e7 A1 : 0x3ffd7c80 A2 : 0x3ffe07a8 A3 : 0x3ffe2710 A4 : 0x0000000c A5 : 0x3ffbbd9c A6 : 0x00000000 A7 : 0x00000000 A8 : 0x801b90d4 A9 : 0x3ffd7c40 A10 : 0x00000000 A11 : 0x3ffe2710 A12 : 0x3ffd5f2c A13 : 0x00000000 A14 : 0x00000000 A15 : 0x3ffd5ed8 SAR : 0x00000002 EXCCAUSE: 0x00000014 EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff ****************************************************************************** Decoding by 
jag
, device has version ****************************************************************************** Backtrace: 0xfffffffd:0x3ffd7c80 0x4011f1e4:0x3ffd7ca0 0x4010ec37:0x3ffd7cc0 0x400dce23:0x3ffd7ce0 0x400dcee5:0x3ffd7d00 0x400e261c:0x3ffd7d20 0x4010e0cd:0x3ffd7d50 jag: Failed to decode line. *********************************************************`********************* `ELF file SHA256: 8e703947df2618a5 Rebooting... ets Jul 29 2019 12:21:46 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:184 load:0x40078000,len:12700 ho 0 tail 12 room 4 load:0x40080400,len:2916 entry 0x400805c4 [toit] INFO: starting [toit] INFO: running on ESP32 - revision 3.0 [jaguar``
f
You might be hitting this issue: https://github.com/toitlang/toit/issues/1390
Let me try to decode the stacktrace you received.
Yep. Looks like it's the same issue:
Copy code
0xfffffffd: _rtc_slow_reserved_end + 0xafffdffd
0x4011f1e4: esp_pbuf_free + 0xc
0x4010ec37: pbuf_free + 0x2f
0x400dce23: toit::LwipSocket::tear_down() + 0x53
0x400dcee5: std::_Function_handler<toit::Object* (), toit::SocketResourceGroup::on_unregister_resource(toit::Resource*)::{lambda()#1}>::_M_invoke(std::_Any_data const&) + 0x9
0x400e261c: toit::LwipEventSource::on_thread(void*) + 0x14
0x4010e0cd: tcpip_thread + 0xa9
@kasperl has a better idea of what exactly the problem is. Maybe he has an easy work-around.
I think one way to avoid the crash is to close down the network by hand before calling deep-sleep. If that's possible.
r
in my code the deepsleep occurs after printing "time to sleep"
Fortunately the device reboots after this error.
f
So from what I understand, it's the shutting down of the containers that's causing this.
r
I also saw: Error: unexpected EOF
f
If there is a network socket that has unread data, it might crash the system.
r
after which the monitor output stops.
f
So there is another issue with "Error: unexpected EOF" and the monitor stopping?
r
Yes, and the program continues its deepsleep cycle
f
The "Error: unexpected EOF" is printed in the terminal that has the 
jag monitor
running?
r
Yes
f
and 
jag monitor
keeps running, but there is no new messages anymore?
even after the device reboots?
Which platform are you on? (Windows, macOS, Linux)
r
No, jag stops
f
To avoid any confusions: what do you mean with "cycle"?
r
I'm on Windows
It is a simple program that starts an MQTT client, does a measuremnt and publishes the result and the ngoes to deep sleep
f
I'm trying to summarize: - you have 
jag monitor
running. - you send a container that triggers 
deepsleep
- at some point (immediately?) the 
jag monitor
program reports "Error: unexpected EOF" and terminates. - the esp32 however continues working. (observed by seeing it publish something?) Is this correct?
r
yes, the error is not immediate
f
interesting. This might be a different behavior on Windows.
r
OK, tomorrow afternoon I will try on Linux
f
It basically says that if a port read returns 0 bytes (but no error) we got an unexpected EOF.
Maybe Windows has a timeout that returns from the 
Read
even if there is no data.
The documentation of the 
Read
function (from the golang package) claims that it should not return with 0 bytes:
Copy code
// Stores data received from the serial port into the provided byte array
    // buffer. The function returns the number of bytes read.
    //
    // The Read function blocks until (at least) one byte is received from
    // the serial port or an error occurs.
    Read(p []byte) (n int, err error)
I will google if others encountered the same issue.
r
I will call it a day, though here in Portugal it's an hour earlier than at your place
f
for you it's 22:34 right?
(23:34 here)
r
Exactly
f
r
Why would monitor read the port?
f
jag monitor
reads the serial port. That's where the messages come from.
r
Sorry, I was thinking from the ESP point of view
f
I will leave you now. If you have new information (like different behavior on Linux) let us know. Also: I don't think we really solved anything for you yet. Make sure we get your attention if nothing happens.
r
Thanks, good night
2 Views
PreviousNext
Powered by