tmr232/Sark

Instruction operands list misbehaves.

Closed this issue · 7 comments

ronyrus commented

The instruction at 'sz_ea' is MOV W3, #0x50
The following test code should print the same operands twice.

            print sark.Line(sz_ea)
            opns = sark.Line(sz_ea).insn.operands
            print opns
            print "------------------------"
            print opns[0]
            print opns[1]
            print "------------------------"
            print sark.Line(sz_ea).insn.operands[0]
            print sark.Line(sz_ea).insn.operands[1]

The output is:

[FFFFFF80206CDFD0]    MOV             W3, #0x50
[<Operand(n=0, text='W3')>, <Operand(n=1, text='#0x50')>]
------------------------
W3
W3
------------------------
W3
#0x50

I've observed other strange behavior related to operands, which is a bit harder to reproduce.
However, I believe that it might be a manifestation of the same problem.

tmr232 commented

This certainly looks wrong.
What is the platform? Arm64?

ronyrus commented

yes, ARM64

tmr232 commented

I'll look into it when I have time. Which probably means next week.

ronyrus commented

Thanks!

tmr232 commented

I can't seem to reproduce it.

Do you have any sample that I can use to reproduce it?

ronyrus commented

I have, not sure I should upload it here though.
Here is another way to reproduce it. I used a random ea from 'ls' executable on iphone (64 bit) with the following code: SUB SP, SP, #0x1A0
And printed the operands number of time in IDA.
Watch the 'n' changes between the prints.
I believe it's the manifestation of the same problem.

Python>ea = ScreenEA()
Python>opns = sark.Line(ea).insn.operands

Python>print opns
[<Operand(n=77, text='')>, <Operand(n=30, text='')>, <Operand(n=2, text='#0x1A0')>]
Python>print opns
[<Operand(n=0, text='SP')>, <Operand(n=0, text='SP')>, <Operand(n=255, text='')>]
Python>print opns
[<Operand(n=0, text='SP')>, <Operand(n=0, text='SP')>, <Operand(n=0, text='SP')>]
Python>print opns
[<Operand(n=0, text='SP')>, <Operand(n=1, text='SP')>, <Operand(n=2, text='#0x1A0')>]
tmr232 commented

Seems like the problem is caused by the insn_t class holding a static array of op_t objects (see ua.hpp). Once the insn_t object is released, the op_t objects are released as well, but the Python code is unaware of that.

I did not run into this issue before because I mostly use the following pattern:

for op in sark.Line().insn.operands:
    do_something_with_op(op)