Make espcoredump more resilient when decoding erroneous thread stack (IDFGH-2802)

[amotl]

We found that espcoredump would stop decoding all subsequent thread stacks when it hits an error like that on a specific thread stack.

  10   process 1073466144 /builds/idf/crosstool-NG/.build/src/gdb-7.10/gdb/inline-frame.c:171: internal-error: inline_frame_this_id: Assertion `!frame_id_eq (*this_id, outer_frame_id)' failed.

This change accounts for that by detecting such a condition and continuing the process appropriately. This helped significantly as espcoredump just decoded thread stacks 19-11 before while it will now also decode thread stacks 9-1, providing valuable additional information.

[Alvin1Zhang]

@amotl Thanks for the contribution.

[amotl]

Thanks, @Alvin1Zhang.

I also wanted to note that this change also removes the shortcut

if thr_id == cur_thread:
    continue

when iterating the threads as I found it convenient to have all thread stacks printed within the "THREADS INFO" section of the output. I didn't see a reason why to omit the particular "current thread" within that output.

[gerekon]

Thanks, @Alvin1Zhang.

I also wanted to note that this change also removes the shortcut

if thr_id == cur_thread:
    continue

when iterating the threads as I found it convenient to have all thread stacks printed within the "THREADS INFO" section of the output. I didn't see a reason why to omit the particular "current thread" within that output.

Because it is printed at the beginning of the core dump, see the very first back trace https://github.com/espressif/esp-idf/blob/master/components/espcoredump/espcoredump.py#L1615-L1623

[gerekon]

LGTM, except for the comment below

[alisitsyn]

Hi @amotl,
Thank you for your PR.
Unfortunately it was not possible to reproduce error similar to your with GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10.

10 process 1073466144 /builds/idf/crosstool-NG/.build/src/gdb-7.10/gdb/inline-frame.c:171: internal-error: inline_frame_this_id: Assertion `!frame_id_eq (*this_id, outer_frame_id)' failed.

Your changes are under review and will be merged as soon as possible.

[amotl]

Hi @alisitsyn,

as we learned from #2892, we are using the -98- toolchain instead of -80-.

./xtensa-esp32-elf-gcc --version
xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-98-g4638c4f) 5.2.0

./xtensa-esp32-elf-gdb --version
GNU gdb (crosstool-NG crosstool-ng-1.22.0-98-g4638c4f) 7.10

Just in this second we see this toolchain might have been made of two different GNUs (5.2.0 vs. 7.10)?

Cheers,
Andreas.

[CLAassistant]

All committers have signed the CLA.

[amotl]

Dear Alexey,

so do you believe this will be fine? I just wanted to make sure that I didn't miss anything and you are waiting for some changes of mine.

With kind regards,
Andreas.

[alisitsyn]

Dear Andreas,

Everything is correct, your PR reviewed and should be merged to github very soon. I appologize for the delay with answer.

[igrr]

Merged in dde4d2e, thanks for the contribution!

[amotl]

Thanks for merging!