This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: overflows in Dwfl_Thread_Callbacks::memory_read callback

On Dienstag, 13. Juni 2017 16:06:01 CEST Mark Wielaard wrote:
> On Thu, 2017-06-01 at 22:46 +0200, Milian Wolff wrote:
> > in the perfparser that Ulf wrote, and to which I'm contributing too, we
> > often see abnormal data being passed to the memory_read callback we
> > define.
> > 
> > I.e. our callback gets invoked with addr=0xFFFFFFFFFFFFFFFF which clearly
> > isn't an expected or valid address. So far we ignored this, as things seem
> > to work okayish, but I still suspect something is wrong somewhere... Out
> > of interest, I would like to ask if anyone has ever seen something like
> > that?
> Yes, you sometimes see that some register or location value is zero for
> some reason, but the expression parser wants to read some memory at an
> offset from that register. e.g. the SP being zero and trying to read at
> SP +/- offset to get some value from the stack.
> Maybe the expression parser should notice this situation and not even
> invoke the memory_read callback in that case since it is obvious it will
> fail.

That would be good to do, I guess. Or at least document that this can happen 
and that it is expected behavior. I.e. right now I simply don't know whether 
our code is buggy and triggering this situation, or whether we are 
encountering something "normal" which just is expected to fail and then some 
fallback code will continue to do the right thing.


> I am not following the above trace completely, but what is going on
> seems to be that we have CFI and want to get a register value. So we
> call dwarf_frame_register to determine the DWARF expression operations
> that we need to execute to get the register value. dwarf_frame_register
> determines that that the register is described by a register offset
> value rule, so it generates operations saying see an the CFA
> (DW_OP_call_frame_cfa) plus some offset (DW_OP_plus_uconst) as a value
> (so read the value from cfa + offset, which is somewhere on the stack).
> But then the cfa comes out as 15? That is obviously bogus. But I don't
> really understand how that happened. It should be a value somewhere near
> the current stack. Then reading 15 - offset (16) clearly fails.

Right, so that cfa value - is that in the DWARF info? So is the dso "broken"? 
Or is this some runtime value that we returned earlier in our register or 
memory callback implementation?


Milian Wolff

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]