Thanks, that was exactly the case, I decoded past the end of a file. I made the wrong assumption that any function must end with a ret instruction, and I decoded addresses until I encountered the first ret instruction. Such, every time there was a function at the end of a file which wouldn't end in a with a ret, the segfault was thrown.
On Wed, Jul 8, 2015 at 6:31 PM, Bill Williams <b...@cs.wisc.edu> wrote: > On 07/05/2015 02:22 PM, Alin Mîndroc wrote: > >> Hi everyone, >> >> I am using DyninstAPI for a project involving disassembling files, and >> it worked perfectly until I had to use it on archive files (static >> libraries .a). >> >> When I try to get the assembly code for librt.a, a segfault is raised >> inside the "ia32_decode_prefixes" method. The strange thing is that it >> fails for a "call" instruction (hex code e8 00 00 00 00), which was >> already parsed successfully before in another function. >> >> Currently, my way of getting assembly code for a function is to >> instantiate a decoder: >> decoder(currentFunction->isrc()->getPtrToInstruction(crtaddr), >> InstructionDecoder::maxInstructionLength, >> currentFunction->isrc()->getArch()); >> Where crtaddr is (last instruction address) + (last instruction size) >> Then, the segfault is thrown for the "call" instruction when I call the >> decode() method on this InstructionDecoder instance. >> >> Any hints on this? Is there any other way of getting assembly code for >> an archive file? >> >> I'd valgrind this. It sounds to me like either your decode buffer has > gone away somehow or you've overrun it; max instruction length could in > fact hit a buffer overrun at the end of a mapped-in file. > > If you're just doing a linear scan disassemble, you can create a decoder > with the full size of the buffer and iteratively decode; that's a safer > approach (assuming that your problem is in fact a buffer overrun). > > Thanks, >> Alin >> >> >> _______________________________________________ >> Dyninst-api mailing list >> Dyninst-api@cs.wisc.edu >> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >> >> > > -- > --bw > > Bill Williams > Paradyn Project > b...@cs.wisc.edu > _______________________________________________ > Dyninst-api mailing list > Dyninst-api@cs.wisc.edu > https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >
_______________________________________________ Dyninst-api mailing list Dyninst-api@cs.wisc.edu https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
