Page 1 of 1

Procexp - shared memory status

PostPosted: Wed Mar 16, 2016 9:18 am
by elist

First, thanks for the really great (and free) tools!
I am trying to debug the VM pages sharing status in my iOS application.
Would it be possible to have the SM= column like in vmmap exist in procexp?


Re: Procexp - shared memory status

PostPosted: Wed Mar 16, 2016 10:24 pm
by morpheus
Sure. All you have to do is ask. Fixed. And your nick is now forever immortalized in the changelog.

Also contains a small but useful fix, showing distance from closest symbol for user mode symbols.

Re: Procexp - shared memory status

PostPosted: Thu Mar 17, 2016 6:38 pm
by elist
Wow, that was a real quick fix!
Thank you so much, honored to have a nick reference in change log :D

Anyway, I was trying to figure out wether UIKit memory (specifically UIViewController) is shared across different applications, so I ran:
root# ~/procexp.universal SpringBoard regions | grep UIKit

And received:
(0) 0xfe310f61 0000000104324000-00000001047bc000 [ 4M]r--/rwx COW /System/Library/Frameworks/UIKit.framework/Artwork.bundle/

so, two questions if I may:
1. why isn't UIKit.framework/UIKit itself listed in the loaded libraries, as expected?
2. Who is responsible to decide whether a library is COW/SHM, and are you familiar with a method to change the sharing configuration (on JB device / on jailed+debugged device)?

Thanks again!

Re: Procexp - shared memory status

PostPosted: Thu Mar 17, 2016 9:58 pm
by morpheus

A) why is UIKit not listed? That's likely because I never got procexp to enumerate all shared libraries in the cache and show individual dylibs (which you can get through TASK_DYLD_INFO and walking them - I might do that soon, when I get time). UIKit is certainly there, but procexp sees the cache as a whole. Again, this is a shortcoming of procexp, certainly. But fixable. Not as fast as the SHM flags, though.

B) The decision is always COW by default, unless otherwise stated. This is not just a XNU thing - all OSes default to implicit sharing, wherein when you mmap (...MAP_PRIVATE..) you get what you THINK is a private copy, but it's in actuality shared with others. Now, anyone modifying such a copy would obviously mess it up for others, hence COW - Copy-on-Write - which means that the writer would get a page fault, which would transparently get the kernel to map a fresh (and writable) copy . If/when that gets written to.

(This is seen better with Linux: try a simple experiment: run and immediately stop a long process like "find /" - suspending just so it runs. Check /proc/that_pid/maps. you'll see eveything mapped as "r...p", seemingly private). Check /proc/that_pid/smaps and still everything shows up private. Then run another instance of find, and check the maps/smaps again - you'll see it's still seemingly private, but actually shared).

So overall - No real reason to explicitly map private unless you're modifying stuff in it. Kernel decides, unless you override.

Re: Procexp - shared memory status

PostPosted: Fri Mar 18, 2016 11:56 am
by elist
I didn't plan to map it as private, but the opposite.
What I would really like to do is to set the mode to SHM (which as I understand is real shared, no Copy On Write) so that my modification will be visible to other processes.
I thought debugging will allow disabling the COW mechanism some how (maybe just skip vm_copy when I write to the COW memory?).
I guess I will try a few things and see for myself :)

Re: Procexp - shared memory status

PostPosted: Fri Mar 18, 2016 12:37 pm
by morpheus
So mmap (...MMAP_SHARED) for that. That makes it explicitly shared; But if others are mapping it private, they get a COW.

Rules for libraries in the shared library cache are a bit different, and you can look into DYLD_SHARED_REGION=[use/private/avoid] for that (man dyld).