Hi John,Â
        
        
        I pulled the latest commit from 
git.dyninst.org, which
          resulted in the error in my previous email.Â
 
        
        
        Now using a clone from the github path your provided, I am
          getting the following message on stderr:Â
        
        
        decodeOneOperand() called with unknown addressing method 18
        
        
        And even though the output binary is created, it does not
          execute (exec format error). Â
        
          
        Again, I am testing with
            /usr/bin/ssh on Ubuntu 16.04, without any instrumentation
            (open, get default module, get procedures, save).
        
        
        Thanks,
        Mohamed
        
        
        
        
          
          Mohamed,
            
            Are you sure you are using the latest master? In my version
            of
            arch-x86.C line 7993 isn't inside the ia32_decode function.
            Could you
            try pulling from master and rebuilding/rerunning? If you
            could provide
            another stack trace that would be really helpful.
            
            -- John
            
            P.S. here is the latest commit information for master
            (http://github.com/dyninst/dyninst):
            
            commit df1523dd4003107b959046dd047402642f530c43
            Merge: 85cebd3 06c649f
            Author: Bill Williams <wwilliam47@xxxxxxxxx>
            Date:Â ÂFri May 27 14:37:50 2016 -0500
            
            Â Â ÂMerge pull request #61 from
            dyninst/Functions_not_filed_into_correct_Modules
            
            Â Â ÂFix Function/Module mapping
            
            On 5/30/2016 9:06 PM, Mohamed Elsabagh wrote:
            > There seems to be a different issue now: calling
            getProcedures() on
            > the default module of a stripped PIE results in an
            assertion failure
            > at common/src/arc-x86.C:7993. It seems that the
            heuristic gap parser
            > is trying to decode the assembly as x86_32 instead of
            x86_64 (I may be
            > wrong though). Exact stack trace is attached.
            >
            > This is triggered by simply opening the binary, getting
            the default
            > module, then calling getProcedure.
            >
            > Sample offending program is /usr/bin/ssh on Ubuntu
            16.04 x86_64.