Re: [DynInst_API:] setting dyninst probes in firefox

[Stan Cox <scox@xxxxxxxxxx>]

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?