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 <s...@redhat.com> 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.
>
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
