-
Notifications
You must be signed in to change notification settings - Fork 511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unhandled FormatField Exception #482
Comments
If you cannot provide the entire ELF file, can you maybe share the section header table (the output of Thanks! |
I don't have the data, but it was a fragment of an elf that was truncated well before the end of the program. The data after the truncation was essentially random as it was forensically carved based on the program headers. The traceback should get you close enough to find the code that did not handle the unexpected input well. If it was never intended to be able to safely parse potentially corrupt elf's that's understandable, but it happens and I figured I'd give you the option. |
The root cause of the error is that the stream ended prematurely. It's consistent with data corruption. I don't see how this is an issue with pyelftools and not with the ELF file. In general, our preferred rule of thumb is - can the GNU or the LLVM tools (e. g. |
The suggestion is to put in an exception indicating that the data is truncated or corrupt in place of the traceback above which is meaningless to users. |
But you already got an exception. Maybe not a very descriptive one, but providing a separate exception type for every possible kind of data corruption out there is not feasible. Here is a very similar discussion: #367 |
Looked at #367, he is reporting the same thing - readelf provides some information about what went wrong and how the elf is malformed. Without that information you're left wondering whether the elf was corrupt or the tool just failed on a valid elf. I agree that the goal should not be to parse the file the same as the Linux kernel loader does, which does not use section headers at all. Again, if it's not a feature that you want to support - don't. |
Barring a clarification from @eliben, I'd say that providing diagnostics on the exact nature of file corruption is not the ambition of this effort. |
I think this is a slightly different issue than #367, which was asking pyelftools to be forgiving and agree to parse a malformed file. That's a clear no. This issue seems to be talking about producing a clearer error message in case this is simple; I don't have any fundamental objections to this, but the caveat is in the is simple. |
This is very likely caused by corruption in an elf file, but I thought you might want to look into the possible cause. Unfortunately I do not have a sample I can provide. Here is the traceback:
The text was updated successfully, but these errors were encountered: