This is a binary that infinite loops with dwarf_next_cfi -1 because the offset
is not updated.
https://rice.box.com/s/yzul9oavplq1qdx12ozjpgssawea36xy
A fix was done by saving the previous *next_off and comparing with the current,
after getting -1 in the return value.
Sasha
From: Mark Wielaard <m...@klomp.org>
Sent: Tuesday, June 5, 2018 6:27:17 AM
To: Sasha Da Rocha Pinheiro; elfutils-devel@sourceware.org
Subject: Re: dwarf_next_cfi returns -1
On Mon, 2018-06-04 at 16:16 +0000, Sasha Da Rocha Pinheiro wrote:
> We had a case where dwarf_next_cfi returns -1 but the offset does not
> update, as we should expect by the comment:
>
> 330 On errors, returns -1. Some format errors will permit safely
> 331 skipping to the next CFI entry though the current one is
> unusable.
> 332 In that case, *NEXT_OFF will be updated before a -1 return.
> Is there a correct way to deal with it, or just check if the NEXT_OFF
> had changed?
A CFI entry starts with the length of that entry, so dwarf_next_cfi can
often setup the next offset correctly. But if there is anything else
"wrong" with the CFI entry (maybe it has a version or augmentation
string not recognized) then it cannot reliably return the CFI entry. It
is indeed a slightly inconvenient interface, you'll have to check
whether the return value, if it is zero, all is fine, if it is 1 you
reached the end, if it is -1 an error occurred. In that last case, if
you really want to try you can try. *next_off having changed after the
call means it might work (or not).
If you have an example of a "wrong" (or not recognized) CFI that would
be helpful.
Thanks,
Mark
