IDAPython functions messing with external func_t object

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open an .idb with sufficient number of functions (e.g. user32.dll).
2. Run the following code in the python CLI:

import idaapi
import idautils
import idc

f = idaapi.get_func(idc.ScreenEA())
print f.startEA
for x in idautils.Heads(f.startEA):
    idaapi.get_func(x)
print f.startEA

What is the expected output? What do you see instead?

The output for the 2 print statements should remain the same. Instead, 
different addresses are printed.

What version of the product are you using? On what operating system?

Running IDA Pro 6.4 32-bit on Windows 7 64-bit (Python 2.7.2).

Problem also manifests on IDA Pro 6.3 32-bit on Windows 7 64-bit (Python 
2.7.2), and IDA Pro 6.1 32-bit on Windows XP 32-bit (Python 2.6.5). All 
versions of IDAPython came by default from the mentioned IDA Pro installations.

Please provide any additional information below.

Original issue reported on code.google.com by smallm...@gmail.com on 15 Feb 2013 at 10:32

[GoogleCodeExporter]

This is actually not IDAPython "messing" with the object. You get the same 
behavior if you use SDK functions in a C++ plugin. What happens is that the 
returned func_t* points inside the internal cache of func_t objects, and as you 
do more get_func() calls eventually that cache slot gets replaced by another 
function.

The solution is simple - you need to use the helper class lock_func, e.g.:

f = idaapi.get_func(here())
print f.startEA
flock = idaapi.lock_func(f) # lock the pointer
for x in idautils.Heads(f.startEA):
    idaapi.get_func(x)
print f.startEA
flock = None # don't need it anymore, free the lock

Original comment by skochin...@gmail.com on 20 Feb 2013 at 1:38

[GoogleCodeExporter]

Thanks for the explanation! Although the design feels a little cumbersome, it 
is good to know how to get things working right :)

Original comment by smallm...@gmail.com on 20 Feb 2013 at 2:49

[GoogleCodeExporter]

Original comment by skochin...@gmail.com on 20 Feb 2013 at 4:02

• Changed state: WontFix