feat: format backtrace with multine

[pyaillet]

Hi and thank you for espmonitor :)

I tried to address #39 with this PR.

Here is the resulting format if you want to check:

***ERROR*** A stack overflow in task (unknown) has been detected.
[panic_abort:/Users/pyaillet/Projets/esp32/twatch-rust/twatch-idf-rs/.embuild/espressif/esp-idf-release/v4.4/components/esp_system/panic.c:402:0x40082e46]:0x3ffd7380
[esp_system_abort:/Users/pyaillet/Projets/esp32/twatch-rust/twatch-idf-rs/.embuild/espressif/esp-idf-release/v4.4/components/esp_system/esp_system.c:128:0x40086c21]:0x3ffd73a0
[vApplicationStackOverflowHook:/Users/pyaillet/Projets/esp32/twatch-rust/twatch-idf-rs/.embuild/espressif/esp-idf-release/v4.4/components/freertos/port/xtensa/port.c:394:0x400896ea]:0x3ffd73c0
[vTaskSwitchContext:/Users/pyaillet/Projets/esp32/twatch-rust/twatch-idf-rs/.embuild/espressif/esp-idf-release/v4.4/components/freertos/tasks.c:3505:0x40088461]:0x3ffd7440
[_frxt_dispatch:/Users/pyaillet/Projets/esp32/twatch-rust/twatch-idf-rs/.embuild/espressif/esp-idf-release/v4.4/components/freertos/port/xtensa/portasm.S:436:0x40086d20]:0x3ffd7470
[_frxt_int_exit:/Users/pyaillet/Projets/esp32/twatch-rust/twatch-idf-rs/.embuild/espressif/esp-idf-release/v4.4/components/freertos/port/xtensa/portasm.S:231:0x40086cd2]:0x00000000

Any suggestions are welcome :)

[pyaillet]

I passed a cargo fmt, let me know if I should not do it.

[kelnos]

I passed a cargo fmt, let me know if I should not do it.

Please don't do this; it makes it really hard to see which lines have changed due to the work you did, vs. just the reformatter. If you could remove that, I'd appreciate it. As long as it passes cargo clippy, that's fine.

[pyaillet]

I passed a cargo fmt, let me know if I should not do it.

Please don't do this; it makes it really hard to see which lines have changed due to the work you did, vs. just the reformatter. If you could remove that, I'd appreciate it. As long as it passes cargo clippy, that's fine.

Ok, no problem. I just reverted the fmt it should be better now.
Let me know if something else needs to be fixed.

Also, the previous code replaced all occurences of 0x4xxxxxxx with function location, the current one does this only if a backtrace pattern is matched

For exemple during the boot sequence in:

ELF file SHA256: 0000000000000000
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:0x3fff0048,len:12
ho 0 tail 12 room 4
load:0x3fff0054,len:4800
load:0x40078000,len:17448
load:0x4007c428,len:4840
entry 0x4007c6a0

The load and entry addresses were also replaced, this is not the case anymore. I don't know if it was done on purpose or not though. It seemed to make sense for the entry but not for the others.

[kelnos]

Hm, so it was a deliberate feature that finding a 0x4xxxxxxx anywhere in a log line would print the function name and location. If you've removed that, then that removes a feature I want to keep. But if you've only removed that in the case when a function name/location isn't found at all, that's fine.

[pyaillet]

No, I've removed it when we are not parsing the stack :\

1. So, would it be ok to handle backtrace parseing separately ?

• When we identify a backtrace, we parse all the functions location and print them one by line
• Otherwise we search for function locations and if we find any, we print the info inline (like it was done before)

2. Should I had the logic to just print the raw log line if we don't have any information ? (the unwrap_or seen here)

[ivmarkov]

I think we are unnecessarily overcomplicating this perhaps?
Instead of trying to locate the [backtrace - whatever prefix, why don't we just:

• Scan each line for tokens which start with 0x4 and contain exactly 7 hexadecimal digits after that?
• After the scanned line is printed, output - on a separate line - the decoding for each found 0x4******* token?

Lower prio: how about having the file name and line number first, and the Rust function name following? Rust function names tend to become long and unreadable when using closures.

[ivmarkov]

I passed a cargo fmt, let me know if I should not do it.

Please don't do this; it makes it really hard to see which lines have changed due to the work you did, vs. just the reformatter. If you could remove that, I'd appreciate it. As long as it passes cargo clippy, that's fine.

Not intending to start a flame war or anything, but you might want to reconsider and add cargo fmt to the CI pipeline. Unlike other languages (e.g. Java), Rust seems to be in the Go camp, in that its one and only standard formatter tends to be a part of the CI. As in there is Only One True Way to format a Rust program, unlike Java, where you have just some recommendation, and then the Eclipse formatting guidelines, Google formatting guidelines etc. etc.

[ivmarkov]

BTW, here's another way to format backtrace output (the standard Rust panics way):
ivmarkov/rust-esp32-std-demo#86 (comment)

I'm not sure we necessarily need the frame numbers in front (what would those even mean when we are not printing a backtrace decoding, but just the decoding for a random 0x4******* PC captured from e.g. a register value or whatever?), but the rest seems quite readable.

[ivmarkov]

See #48

[pyaillet]

Thank you @ivmarkov !