ASSERT (r2693) add_vm_area:vmareas.c:987 in client.modules

_From [byron.c....@gmail.com](https://code.google.com/u/101184679827294438523/) on June 06, 2014 05:58:07_
1. Modify client.modules to load a toy module in linux instead of libz.so.1
2. Run the test on an x86 build

The client loads and unloads a toy module via dr_[un]load_aux_library() during dr_init(). The corresponding vm area is retained with all metadata set to zero (because the memory is still allocated to the process). In the target app's main(), it loads another toy module of the same size, which the OS puts in the same location as the earlier aux module. Since a vm area exists there, memcache_handle_mmap() calls app_memory_protection_change() with the the new `prot` of 5 (r-x). According to the comment there:

/\* We detect some alloc-based prot changes here. app_memory_pre_alloc()
- should have already processed these (issue #1175) but no harm calling
- app_memory_protection_change() again just in case.
*/

Since the new module is not loaded yet, app_memory_protection_change() thinks the vm area is `!executable && MEMPROT_EXEC`, and adds a phantom area to the vm list having !VM_UNMOD_IMAGE. As the module loading proceeds, a properly formed (non-phantom) vm area is added, but the assert at vmareas.c:987 finds the phantom with !VM_UNMOD_IMAGE and says it should not be replaced with the new VM_UNMOD_IMAGE.

I can think of 2 resolutions:
1. If memcache_handle_mmap() adds a phantom vm area, then the phantom should somehow be marked as such.
2. memcache_handle_mmap() could probably figure out that the existing vm area is totally empty and just ignore it.

Perhaps the best thing would be to completely delete the vm area after the aux module is unloaded, but I think that is not possible because the memory region is still allocated to the process and does need to be accounted for.

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1456_