Error when extending IRSBs

[seankramer]

My program integrates C code and calls pyvex/angr through it. Within the C code I lift basic blocks to vex, and then combine basic blocks for indirect call/jump solving. When there are two preceding blocks to the same IRSB, pyvex gets a strange error when combining the second of the two blocks.

Although it says that the blocks have been combined (the program does not fail), attempting to pretty print the newly combined block will fail. Going statement by statement, pyvex only prints out the statement for the first instruction, but upon encountering the second statement 02 | t13 = GET:I64(rsp) , I get the following error:

enums.py:84: RuntimeWarning: tp_compare didn't return -1 or -2 for exception return ints_to_enums[i]

When manually getting the bytes of each block and combining them, it works without errors, but when calling the extend method the error will arise

EDIT: after adding PyErr_Print to the code: the error is:
File "pyvex/block.py", line 211, in extend
stmt_.tmp = convert_tmp(stmt_.tmp)
File "pyvex/block.py", line 193, in convert_tmp
tmp_type = extendwith.tyenv.lookup(tmp)
File "pyvex/block.py", line 578, in lookup
return self.types[tmp]
IndexError: list index out of range

[rhelmot]

You mentioned this was resolved on slack, but can you provide a testcase to reproduce regardless? I want to understand the issue and maybe provide a better error message.

[seankramer]

Sorry for the delay. I could re-create the problem by using the following code:

 pic0 = pyvex.lift("\x89\xc0\x48\x8d\x14\x85\x00\x00\x00\x00"
    "\x48\x8d\x05\x73\x01\x00\x00\x8b\x04\x02"
    "\x48\x63\xd0\x48\x8d\x05\x66\x01\x00\x00"
    "\x48\x01\xd0\xff\xe0", 0x400538, archinfo.get_host_arch())

pic1 = pyvex.lift("\x55\x48\x89\xe5\x89\xf8"
    "\x88\x45\xec\x0f\xbe\x45\xec"
    "\x83\xf8\x0f\x77\x71", 0x400526, archinfo.get_host_arch())

pic2 = pyvex.lift("\x55\x48\x89\xe5\xbf\x09\x00"
    "\x00\x00\xe8\x5d\xff\xff\xff", 0x4005bb, archinfo.get_host_arch())

pic0.extend(pic2)
pic1.extend(pic2)

`

[rhelmot]

Yes, hm. This is definitely an issue. Block extension is a destructive operation on the second block, reusing the statement and expression objects as an optimization since the only usecase had previously been stitching together blocks from different lifters, where the goal was to produce one coherent block that would supercede any need to use either of the original blocks.

@subwire @lockshaw what do you think of this? should there be a usecase for nondestructive extension or should we just document the caveat and move on?

[github-actions]

This issue has been marked as stale because it has no recent activity. Please comment or add the pinned tag to prevent this issue from being closed.