Coredump (elf) data shiftted, causing idf.py coredump-debug not working (IDFGH-9491) #10852
Closed
3 tasks done
Assignees
Labels
Resolution: Done
Issue is done internally
Status: Done
Issue is done internally
Type: Bug
bugs in IDF
Comments
github-actions
bot
changed the title
That part — that the ELF magic is not at the beginning of the coredump partition — is expected and this should be the case every time. In flash, the ELF formatted coredump is prefixed with a header: Since the coredump-debug command is failing, it's probably a real bug somewhere, though. Thank you for the attached files, we will try to reproduce the issue and debug it. |
|
@wuyuanyi135 for what it's worth, I'm able to debug the unmodified core dump from the attachment using: I think the problem might be in the part of the script which reads the core dump from flash (this one) — perhaps it doesn't actually read the entire core dump partition. Could you please see if there's anything useful in the output you get from |
|
@igrr Thanks for your quick response and explanation! For the prefixed coredump, I guessed it should be the case since the docs hint so. However, I traced the stacktrace when executing esp-idf/tools/idf_py_actions/debug_ext.py Line 194 in 57b6be2 As you may see, it checks the elf magic at the begining of the file. I guess if the coredump was created by Also, I noticed you were using another script |
|
@igrr For your second request, I attach the full stacktrace here. |
|
And I do agree with you that might be some serial connection (the built-in USB-JTAG) problem. I occasionally experience jammed flashing that stopped at certain percent of uploading and CTRL-C could not stop the program - I have to either unplug or reset the board and then it will dump tons of output suddenly. The PCB and electronics should be fine. I used the USB interface for communication in my app and it worked very stable. Only in bootloader did I experienced the interrupted data transfer. IIRC, this happens since a while ago, and I also felt that the flashing speed gots faster, maybe the bootloader or the flash tool were changed recently? |
|
I also leave my sdkconfig here, in case it provides some insights sdkconfig |
|
Ah, i see. So the actual error is here: Basically, esptool.py has failed to read the coredump partition and exited half-way. Then instead of exiting from the So the issue you are facing is probably with esptool.py read_flash not working reliably. I would suggest running this command manually a few times. If you get it to fail occasionally, please check the troubleshooting instructions in https://github.com/espressif/esptool, then in case you can't figure out what the issue is, open a bug report in esptool repository. The issue that we can fix in this ticket is that
|
|
@igrr Many thanks for your detailed explanation. Yes, I agree that the output should be improved so that the actual problem will not be masked. I will keep monitoring if the bootloader I/O problem persists and open a issue in esptool repository. |
|
@igrr in addition to what you suggest, it also worth noting that the coredump-debug handles the core file differently. When passing the prefixed coredump it assumes it is a base64 encoded file rather than raw elf due to magic check. Maybe this should also be documented or covered. |
Thanks for pointing it out. It does have the logic to distinguish the two, but we have forgotten to consider that the chip ID is also stored as part of the version/magic field here. We'll get that fixed, as well. |
espressif-bot
added
Resolution: NA
espressif-bot
added
Resolution: Done
|
I'm experiencing a similar issue and I don't know where I should post it. Had I had |
|
@dizcza it should be available AFAIK. Also, upgrading esptool to 4.6 rather than 4.5 shipped with 5.0 will drastically improve the stability during flashing and coredumping. |
espressif-bot
added
Status: Opened
espressif-bot
added
Status: Selected for Development
espressif-bot
added
Resolution: NA
espressif-bot
pushed a commit
that referenced
this issue
Dec 16, 2023
When idf.py coredump-debug is launched with '--core' argument, it tries to determine the file format (raw, elf, b64). To detect the 'raw' core dump the code checked if the version word matched one of the known values. However, the version word also contains the chip ID in the high half-word, so the check failed for anything other than the ESP32. The detection of core file format has been moved to esp-coredump package in version 1.9.0, including the fix for chip ID. Reported in #10852
espressif-bot
pushed a commit
that referenced
this issue
Dec 18, 2023
When idf.py coredump-debug is launched with '--core' argument, it tries to determine the file format (raw, elf, b64). To detect the 'raw' core dump the code checked if the version word matched one of the known values. However, the version word also contains the chip ID in the high half-word, so the check failed for anything other than the ESP32. The detection of core file format has been moved to esp-coredump package in version 1.9.0, including the fix for chip ID. Reported in #10852
espressif-bot
pushed a commit
that referenced
this issue
Jan 29, 2024
When idf.py coredump-debug is launched with '--core' argument, it tries to determine the file format (raw, elf, b64). To detect the 'raw' core dump the code checked if the version word matched one of the known values. However, the version word also contains the chip ID in the high half-word, so the check failed for anything other than the ESP32. The detection of core file format has been moved to esp-coredump package in version 1.9.0, including the fix for chip ID. Reported in #10852
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Answers checklist.
IDF version.
v5.1-dev-3636-g66ab22986f
Operating System used.
Windows
How did you build your project?
CLion IDE
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
ESP32-S3-WROOM-1-N8R8
Power Supply used.
USB
What is the expected behavior?
What is the actual behavior?
I found occasionally,
idf.py coredump-debugfails with the following stacktrace:Therefore, I dump the coredump partition. Supurisingly, it does not starts with the ELF magics (0x7f,E, L, F). See the picture below, the magic bytes in the circle are supposed to be the first bytes.
I then remove the bytes before the ELF header then debug with
idf.py coredump-debug --core coredumpand it works without problem!Steps to reproduce.
I could not reproduce this error consistently. The coredump partition occasionally broke.
Debug Logs.
No response
More Information.
Partition Table:
Attached archive contains the elf symbol file, modified coredump that can be debugged, and unmodified coredump.
coredump.zip
The text was updated successfully, but these errors were encountered: