Page 1 of 1

Coredump question

Posted: Mon Nov 19, 2018 2:43 pm
by kluverp
Hi follow ESP32 users,

I have the following coredump:

Code: Select all

==================== CURRENT THREAD STACK =====================
#0  0x4008fecf in esp_core_dump_write_flash_padded (data_size=12, data=0x3ffcab00 \"\", off=0) at /home/peter/esp/esp-idf-v3.1/components/esp32/core_dump.c:291
#1  esp_core_dump_flash_write_data (priv=0x2f, data=0x3ffcab00, data_len=12) at /home/peter/esp/esp-idf-v3.1/components/esp32/core_dump.c:398
#2  0x4009002a in esp_core_dump_flash_write_end (priv=0xc8) at /home/peter/esp/esp-idf-v3.1/components/esp32/core_dump.c:376
#3  0x400d9542 in fiprintf (fp=0x3f403c65 <__FUNCTION__$5711>, fmt=0x69 <error: Cannot access memory at address 0x69>) at ../../../.././newlib/libc/stdio/fiprintf.c:50
#4  0x4008d150 in prvCheckTasksWaitingTermination () at /home/peter/esp/esp-idf-v3.1/components/freertos/tasks.c:3706
#5  prvIdleTask (pvParameters=<optimized out>) at /home/peter/esp/esp-idf-v3.1/components/freertos/tasks.c:3388
#6  0x4008c4b2 in uxQueueSpacesAvailable (xQueue=0xffffffb8) at /home/peter/esp/esp-idf-v3.1/components/freertos/queue.c:1773
#7  0x40154185 in tcp_receive (pcb=0x3ffaffc8) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/tcp_in.c:1081
#8  0x40154d8c in tcp_input (p=0x3ffc2b70 <renew>, inp=<optimized out>) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/tcp_in.c:175
#9  0x40149ae1 in sys_timeouts_init () at /home/peter/esp/esp-idf-v3.1/components/lwip/core/timers.c:186
#10 0x40149e10 in pbuf_alloc (layer=<optimized out>, length=0, type=1073490768) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/pbuf.c:257
#11 0x4014a225 in pbuf_take_at (buf=<optimized out>, dataptr=0x3ffde4b0, len=3630, offset=<optimized out>) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/pbuf.c:1141
#12 0x4014bc5d in tcp_keepalive (pcb=0x40082c74 <_calloc_r+28>) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/tcp_out.c:1531
#13 0x4014bcf2 in tcp_zero_window_probe (pcb=0x3ffcace0) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/tcp_out.c:1582
#14 0x40146e4a in lwip_getsockopt_r (s=1074703136, level=0, optname=0, optval=0x0, optlen=0x0) at /home/peter/esp/esp-idf-v3.1/components/lwip/api/sockets.c:3290

======================== THREADS INFO =========================

The thing is, how to interpret this?
Where does it go wrong? Does it crash during creation of the coredump?

Re: Coredump question

Posted: Mon Nov 19, 2018 6:04 pm
by Ritesh
kluverp wrote:
Mon Nov 19, 2018 2:43 pm
Hi follow ESP32 users,

I have the following coredump:

Code: Select all

==================== CURRENT THREAD STACK =====================
#0  0x4008fecf in esp_core_dump_write_flash_padded (data_size=12, data=0x3ffcab00 \"\", off=0) at /home/peter/esp/esp-idf-v3.1/components/esp32/core_dump.c:291
#1  esp_core_dump_flash_write_data (priv=0x2f, data=0x3ffcab00, data_len=12) at /home/peter/esp/esp-idf-v3.1/components/esp32/core_dump.c:398
#2  0x4009002a in esp_core_dump_flash_write_end (priv=0xc8) at /home/peter/esp/esp-idf-v3.1/components/esp32/core_dump.c:376
#3  0x400d9542 in fiprintf (fp=0x3f403c65 <__FUNCTION__$5711>, fmt=0x69 <error: Cannot access memory at address 0x69>) at ../../../.././newlib/libc/stdio/fiprintf.c:50
#4  0x4008d150 in prvCheckTasksWaitingTermination () at /home/peter/esp/esp-idf-v3.1/components/freertos/tasks.c:3706
#5  prvIdleTask (pvParameters=<optimized out>) at /home/peter/esp/esp-idf-v3.1/components/freertos/tasks.c:3388
#6  0x4008c4b2 in uxQueueSpacesAvailable (xQueue=0xffffffb8) at /home/peter/esp/esp-idf-v3.1/components/freertos/queue.c:1773
#7  0x40154185 in tcp_receive (pcb=0x3ffaffc8) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/tcp_in.c:1081
#8  0x40154d8c in tcp_input (p=0x3ffc2b70 <renew>, inp=<optimized out>) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/tcp_in.c:175
#9  0x40149ae1 in sys_timeouts_init () at /home/peter/esp/esp-idf-v3.1/components/lwip/core/timers.c:186
#10 0x40149e10 in pbuf_alloc (layer=<optimized out>, length=0, type=1073490768) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/pbuf.c:257
#11 0x4014a225 in pbuf_take_at (buf=<optimized out>, dataptr=0x3ffde4b0, len=3630, offset=<optimized out>) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/pbuf.c:1141
#12 0x4014bc5d in tcp_keepalive (pcb=0x40082c74 <_calloc_r+28>) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/tcp_out.c:1531
#13 0x4014bcf2 in tcp_zero_window_probe (pcb=0x3ffcace0) at /home/peter/esp/esp-idf-v3.1/components/lwip/core/tcp_out.c:1582
#14 0x40146e4a in lwip_getsockopt_r (s=1074703136, level=0, optname=0, optval=0x0, optlen=0x0) at /home/peter/esp/esp-idf-v3.1/components/lwip/api/sockets.c:3290

======================== THREADS INFO =========================

The thing is, how to interpret this?
Where does it go wrong? Does it crash during creation of the coredump?

Hi,

Just want to know that core dump is from top to bottom or bottom to top? So that you can trace crash dumps according to that sequence with function name, file name and line number.

Re: Coredump question

Posted: Tue Nov 20, 2018 6:51 am
by kluverp
I assume top to bottom right? With top being the latest function?

The top row says:

Code: Select all

0x4008fecf in esp_core_dump_write_flash_padded (data_size=12, data=0x3ffcab00 \"\", off=0) at /home/peter/esp/esp-idf-v3.1/components/esp32/core_dump.c:291
What does this tell me?

Re: Coredump question

Posted: Tue Nov 20, 2018 12:52 pm
by Ritesh
kluverp wrote:
Tue Nov 20, 2018 6:51 am
I assume top to bottom right? With top being the latest function?

The top row says:

Code: Select all

0x4008fecf in esp_core_dump_write_flash_padded (data_size=12, data=0x3ffcab00 \"\", off=0) at /home/peter/esp/esp-idf-v3.1/components/esp32/core_dump.c:291
What does this tell me?
As you have mentioned into your first post that is it crash dumped or core dumped? if it is crash dumped then it should be from bottom to top in which top most would be last execution call before crashing system

Hope this will be helpful information as per your requirement and let me know if you need any more information for same.