Re: [DynInst_API:] setting dyninst probes in firefox

[mxz297@xxxxxxxxx]

I think I understand whatâs going on and know how to fix it. Can you send me this .so? I want to ensure that I fixed it. 

> On Apr 2, 2020, at 1:56 PM, Stan Cox <scox@xxxxxxxxxx> wrote:
> 
> So what seems to happen (this is upstream sources) is when parsing libXcursor.so.1.0.2 at the function "XcursorTryShapeBitmapCursor" (end of .so):
> 00000000000085f0 <XcursorTryShapeBitmapCursor@@Base>:
>    85f0:       f3 0f 1e fa             endbr64
>    85f4:       41 57                   push   %r15
>    85f6:       41 56                   push   %r14
> ...
>    8712:       c3                      retq
>    8713:       e8 48 b0 ff ff          callq  3760 <__stack_chk_fail@plt>
> Disassembly of section .fini:
> 0000000000008718 <.fini>:
>    8718:       f3 0f 1e fa             endbr64
>    871c:       48 83 ec 08             sub    $0x8,%rsp
>    8720:       48 83 c4 08             add    $0x8,%rsp
>    8724:       c3                      retq
> 
> In Dyninst::ParseAPI::Parser::parse_frame_one_iteration(Dyninst::ParseAPI::ParseFrame&,..)
> 
> The line:
> const unsigned char* bufferBegin = (const unsigned char *)(func->region()->getPtrToInstruction(curAddr));
> 
> where func->region().{low,high} = 0
> yields bufferBegin is 0
> causing dec.start = 0
> and the decoder subsequently fails.
> 
> This m_buf.start check seems to bypass that, but is probably treating a symptom and not a cause.
> 
> INSTRUCTION_EXPORT Instruction InstructionDecoder::decode()
>    {
>      if(!m_buf.start || m_buf.start >= m_buf.end) return Instruction();
>      return m_Impl->decode(m_buf);
>    }
> 
> I hit a later problem; analyzing that now.
> 
> PS  Do regions typically correspond to the storage space of a function? block? other?

A region typically corresponds to a section in an ELF file. 

>