The meaning of output of pmap

Question

Overview:

I have an iOS project in which I am using core data

• I have an Employees entity and a Department entity.
• 1 department can contain many employees
• So the entity Department has a "to many" relationship with the entity Employees, the relationship is called employees and the reverse relationship is called whichDepartment

Aim-1:

I want to delete all the employees in a specific department

Questions:

a) is the following correct, or would it cause mutation or some problems ?

b) is this is the correct way to do it ?

Pls Note - removeEmployees is a method that was auto generated while creating the subclasses of the entities

- (void) deleteAllEmployeesForDepartment: (Department*) requestedDepartment
{
    [requestedDepartment removeEmployees:requestedDepartment.employees];
}

Aim-2:

• I want to delete the employees based on some condition
• I am deleting objects inside a fast enumeration loop for the fetched records

Questions:

c) Is the following correct, or would it cause some mutation ?

d) Is it like modifying the object in fast enumeration ?

e) Is there a better way to do it ?

Pls Note - removeEmployees is a method that was auto generated while creating the subclasses of the entities

- (void) deleteAllType1EmployeesWithDepartment: (Department*) requestedDepartment
{ 
    fetchRequest.predicate = [NSPredicate predicateWithFormat:@"type == %i AND whichDepartment ==%i", 1, requestedDepartment.departmentID];

    NSError *error;
    NSArray *listOfEmployeesToBeDeleted = [self.managedObjectContext executeFetchRequest:fetchRequest error:&error];    

    for(Employees *currentEmployee in listOfEmployeesToBeDeleted)
    {       
       [self.managedObjectContext deleteObject:currentEmployee];
    }
}

Solution

The text segment is the mapping at 0x400000 - it's marked 'r-x' for readable and executable. The mapping at 0x600000 is read-only, so that's almost certainly the ".rodata" section of the executable file. GCC puts C string literals into a read-only section. The mapping at 0x601000 is 'rw-', so that's probably the famed heap. You could have your executable malloc() 1024 bytes and print out the address to see for sure.

You might get a little bit more information by finding the PID of your process, and doing: cat /proc/$PID/maps - on my Arch laptop, that gives some extra info. It's running a 3.12 kernel, so it also has /proc/$PID/numa_maps, and catting that might give a small insight, too.

Other things to run on the executable file: nm and objdump -x. The former can give you an idea of where various things lie in the memory map, so you can see what's in the 0x4000000 section vs the other sections. objdump -x shows you ELF file headers among lots of other things, so you can see all the sections, complete with section names and whether they're mapped in a run time or not.

As far as finding a written explanation of "what is where", you'll have to do things like google for "ELF FILE memory layout". Be aware that the ELF file format can support more exotic memory layouts than commonly get used. GCC and Gnu ld and glibc all make simplifying assumptions about how an executable file gets laid out and then mapped into memory at run time. Lots of web pages exist that purport to document this, but only apply to older versions of Linux, older versions of GCC or glibc, or only apply to x86 executables. If you don't have it, get the readelf command. If you can write C programs, create your own version of objdump -x or readelf to become familiar with how executable files work, and what's in them.

Comments

[Danila Ladner]

text segments are actually read only, so it is at 0000000000600000 .

[Thorsten Staerk]

Thanks! Shouldn't the text segment be executable as well?

[user1046037]

thanks Daniel, I just tested the methods deleteAllEmployeesForDepartment and clearEmployeesOfType. Both these methods seem to be causing the whichDepartment (relationship) field to become NULL. I think the reason for this may be because internally fast enumeration or something similar might be used to loop through the NSSet, and deleting an object from the same set which is used in fast enumeration is causing this to happen. However fetch requests and looping through them and using deleteObject seems to work ok.

[Thorsten Staerk]

Great answer. Now, where is the program's heap? And what does this [ anon ] mean? What do I have to google to find this out?

[Admin]

You know what? I was wrong about the 0x601000 address mapping - that's the heap, probably. You'll have to use readelf or objdump to figure it out, and whatever the executable you've made. My Arch linux box uses /usr/lib/libc-2.18.so, so it's quite different than your box.

[ninjalj]

0x601000 is the data segment. It contains .data, .bss and can be extended via brk(). [anon] indicates non-file backed memory (so backed by swap), obtained via mmap(). dlmalloc uses brk() for allocations smaller than ~64Kb IIRC, and mmap() for larger allocations. The heap is everything allocated by malloc, both the extended part of the data segment, and the mmap()-based allocations.