0

Hi I am running an application where the the Dex file instructions were having address or PC like 0x000253DC but when i get live instructions traces the PC or addresses are like 41ed7748 They are completely different in range.

I am just wondering is it normal or I am getting the traces wrong?

Thanks.

P basak
  • 4,874
  • 11
  • 40
  • 63

1 Answers1

0

The addresses in native crash stack traces on Android appear as library offsets, so the high bits will be zeroed. Since the library location may change from run to run, the high part of the address is not included in stack traces.

See e.g. this question.

(None of which has anything to do with Dalvik bytecode, so I'm a little confused about the DEX file reference. Hopefully I'm not completely off base.)

Community
  • 1
  • 1
fadden
  • 51,356
  • 5
  • 116
  • 166
  • hi let me clarify, I can get dalvik instructions from the dex file using dexdump, it has follwoing format 00041ead: 12f0 where the first 12 bits are zeroed out as you say. Now if I can get the runtime instruction traces, I end up getting something like 41ed7748: 12f0. my question is to map the instructions from the dex to the trace I got, how can match the pc offsets. So that I can know which instructions from the dex file were executed? – P basak Nov 19 '13 at 09:00
  • DEX files are also memory-mapped, so I would expect the low bits of the addresses to match up there as well. From where are the "runtime instruction traces" coming? Can you show an example? Traces for managed code don't usually show the address. – fadden Nov 19 '13 at 15:50
  • Hi i hooked into dalvik code and printed the instructions in the log. – P basak Nov 21 '13 at 22:26
  • Ah. You need to dump `/proc//maps` to figure out the base address of the DEX file mapping, and subtract that off to get the offset into the DEX file. Similar to what you do for native PCs; see http://stackoverflow.com/questions/20001153/android-how-to-analyse-the-native-heap-dump/20012337#20012337 – fadden Nov 21 '13 at 23:00
  • here is the maps dump for news app npr, https://www.dropbox.com/s/a84ocmmwnm6tn0v/mapsnpr.txt should I look for 448fc000-4494f000 r--p 00000000 b3:39 147562 /data/dalvik-cache/data@app@org.npr.android.news-1.apk@classes.dex because there are so many things. ? – P basak Nov 22 '13 at 21:25
  • The numbers on the left are the address range for the mapping. When you get an address, figure out what mapping it's a part of, and subtract off the lower address. These will likely be different every time the app is run. Alternatively, since you're printing messages from inside Dalvik, you may be able to just get `method->clazz->pDvmDex->memMap.baseAddr` and subtract that off before logging it. – fadden Nov 22 '13 at 21:55
  • Thanks for the input I will have my tests and let you know. – P basak Nov 22 '13 at 22:01
  • did you mean something like this? (int)pc-(int)curMethod->clazz->pDvmDex->memMap.baseAddr btw where I can find the structure of curMethod? I do not find that by using ctag. – P basak Nov 27 '13 at 09:08
  • and another thing, the difference does not seem exact matching. I am running in interpreter mode so that the jit is disabled. What I think the memory assignment is not related to the exact amount of memory array in the code region. the code may not be sequential in that memory region assigned. – P basak Nov 27 '13 at 09:55
  • `struct Method` is defined in `oo/Object.h`, https://android.googlesource.com/platform/dalvik/+/kitkat-release/vm/oo/Object.h . The memory map is linear. – fadden Nov 27 '13 at 16:26
  • I have done the mapping from the memory to the actual offset in the dex file. They are not same. DO you thik the reason behind that dalvik is actually running optimized dex (using dexopt) during xecution which is not similar with the dex instructions in the file? – P basak Dec 04 '13 at 02:51
  • dexopt can change instructions, but it just rewrites them in place -- the file doesn't change size, and nothing moves around. The post-dexopt version of the DEX file can be found in `/data/dalvik-cache`. – fadden Dec 04 '13 at 02:55
  • /data/dalvik-cache/data@app@org.npr.android.news-1.apk@classes.dex I got this for the app rg.npr.android.news-1.apk. But does it only store the data area? Or the optimized dex? – P basak Dec 04 '13 at 02:59
  • It has classes.dex, unzipped from the APK, and processed with dexopt. Run it through `dexdump` and see. If you look at the hex dump, you'll see that it has a short header appended to the front. – fadden Dec 04 '13 at 03:33
  • So, it should be more accurate if I work with this processed dex right? I mean as far as the instructions are concerned? – P basak Dec 04 '13 at 09:46
  • The odex version is what's being executed, so yes, it's more accurate. On the other hand, it can be harder to figure out what the code is doing (e.g. interpreting an execute-inline instruction). – fadden Dec 04 '13 at 15:42
  • well i extracted the dx file from /data/dalvik-cache but it seems it only contains the definition of classes, not actual instructions. – P basak Dec 06 '13 at 01:39
  • You can use `dexdump -d` to see the instructions. – fadden Dec 06 '13 at 06:33
  • can you tell me whether dalvik keeps any thread safety in printing log instructions? I mean if two threads race for the same variable the order of execution may not be deterministic. So, does the logged instruction keeps any form of determinism? for example if two threads access a particular shared memory at the same time which order the execution trace will be printed? – P basak Feb 04 '14 at 23:36
  • Dalvik largely adheres to the Java Memory Model (cf. http://stackoverflow.com/questions/4588076/). There's no guarantees on thread execution order, and there's no guarantee that the thread that accessed a memory location won't be interrupted before it has a chance to write the log message (which could yield an apparently wrong order on a uniprocessor). If you need determinism, you need to use some sort of synchronization operation. – fadden Feb 05 '14 at 00:15
  • my problem is a bit different. in the main interpreter loop of dalvik source, printing instructions by enabling the logged instruction flag. Does the interpreter loop preserves the order of execution? if thread 1 changes a value before thread 2 will the instruction logging in the interpreter loop preserve this? Actually I am trying to do some back propagation to track back to a particular source of a failure (by analyzing the def-use pairs). So, if the instruction dumping process is on par with the actual instruction execution sequence than it is ok. I hope I managed to explain the scenario. – P basak Feb 05 '14 at 20:59
  • I wouldn't assume it's any less asynchronous than it is without logging. Your statement that "thread 1 changes a value before thread 2" implies that the threads have coordinated in some way to define a happens-before relationship, but I assume that's not the case or there wouldn't be a question. :-) Even if the value changed were a "volatile" field, there is still no guarantee of atomicity for {access memory, write a log message}, so I don't believe you can make any statements about the order of accesses to memory based on instruction logging. It might be a fair approximation though. – fadden Feb 05 '14 at 22:28
  • ok I got it, that means just looking at the log instruction sequence is not enough for situations like data race. right? – P basak Feb 06 '14 at 23:51
  • can you have a look on this question? http://stackoverflow.com/questions/24791339/the-interpretor-for-android-art-runtime – P basak Jul 16 '14 at 21:54