ASSERT vm_area overlap on OSX 10.15 Catalina
I'm just trying to get rid of the CMP0042 warning in #1375 (closed) which annoys developers on all platforms, but the Mac I'm testing on has the new version Catalina 10.15 and there we hit this assert:
$ bin64/drrun -- suite/tests/bin/simple_app
<Starting application /Users/derek/dr/git/build_x64_dbg/suite/tests/bin/simple_app (56298)>
<Application /Users/derek/dr/git/build_x64_dbg/suite/tests/bin/simple_app (56298) is running on an unsupported operating system (19.0.0)>
<Initial options = -no_dynamic_options -code_api -stack_size 56K -signal_stack_size 32K -max_elide_jmp 0 -max_elide_call 0 -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct >
<Application /Users/derek/dr/git/build_x64_dbg/suite/tests/bin/simple_app (56298). Internal Error: DynamoRIO debug check failure: /Users/derek/dr/git/src/core/vmareas.c:945 !(start < v->buf[i].end && end > v->buf[i].start) || !TEST(VECTOR_NEVER_OVERLAP, v->flags)
(Error occurred @0 frags)
It is coming from the +rw data segment of two libraries overlapping:
Module 4: 0x00007fff68fc2000 /usr/lib/system/libcache.dylib
module_walk_program_headers: segment __TEXT addr=0x63c97000 sz=0x6000 file=0x43c97000
module_walk_program_headers: segment __DATA addr=0x90cb5310 sz=0x128 file=0x60549310
module_walk_program_headers: segment __LINKEDIT addr=0xc05c0000 sz=0x15bf8a3c file=0x6127f000
module_walk_program_headers: lib identity libcache.dylib
module_walk_program_headers: exports addr=0x626db538 sz=0x290
module_walk_program_headers: bounds 0x00007fff63c97000-0x00007fffd61b8a3c
dyld shared cache is 0x00007fff2532b000-0x00007fffd86b0000
in add_vm_area 0x00007fff68fc2000 0x00007fff68fc8000
=> adding 0x00007fff68fc2000-0x00007fff68fc8000
module <no name> segment [0x00007fff68fc2000,0x00007fff68fc8000] added
in add_vm_area 0x00007fff95fe0000 0x00007fff95fe1000
=> adding 0x00007fff95fe0000-0x00007fff95fe1000
module <no name> segment [0x00007fff95fe0000,0x00007fff95fe1000] added
segment list
segment 0: [0x00007fff68fc2000,0x00007fff68fc8000) prot=5
segment 1: [0x00007fff95fe0000,0x00007fff95fe1000) prot=3
segment 2: [0x00007fffc58eb000,0x00007fffdb4e4000) prot=1
module libcache.dylib |libcache.dylib| [0x00007fff68fc2000,0x00007fff68fc3000] added
Module 5: 0x00007fff68fc8000 /usr/lib/system/libcommonCrypto.dylib
module_walk_program_headers: segment __TEXT addr=0x63c9d000 sz=0xc000 file=0x43c9d000
module_walk_program_headers: segment __DATA addr=0x90cb5440 sz=0x14c0 file=0x60549440
module_walk_program_headers: segment __LINKEDIT addr=0xc05c0000 sz=0x15bf8a3c file=0x6127f000
module_walk_program_headers: lib identity libcommonCrypto.dylib
module_walk_program_headers: exports addr=0x626db7c8 sz=0x1170
module_walk_program_headers: bounds 0x00007fff63c9d000-0x00007fffd61b8a3c
dyld shared cache is 0x00007fff2532b000-0x00007fffd86b0000
vmm_heap_commit vmheap: size=4096 p=0x00000001716c1000 prot=3
os_heap_commit: 4096 bytes @ 0x00000001716c1000
in add_vm_area 0x00007fff68fc8000 0x00007fff68fd4000
=> adding 0x00007fff68fc8000-0x00007fff68fd4000
module <no name> segment [0x00007fff68fc8000,0x00007fff68fd4000] added
in add_vm_area 0x00007fff95fe0000 0x00007fff95fe2000
In fact the vmmap
program shows them sharing pages?!?
__DATA 00007fff95ec0000-00007fff95ec9000 [ 36K 36K 16K 0K] rw-/rwx SM=COW /usr/lib/libobjc.A.dylib
unused shlib __DATA 00007fff95fe0000-00007fff95fe0310 [ 784 784 784 0K] rw-/rwx SM=COW unused system shared lib __DATA, on dirty page
__DATA 00007fff95fe0310-00007fff95fe0438 [ 296 296 296 0K] rw-/rwx SM=COW /usr/lib/system/libcache.dylib
unused shlib __DATA 00007fff95fe0438-00007fff95fe0440 [ 8 8 8 0K] rw-/rwx SM=COW unused system shared lib __DATA, on dirty page
__DATA 00007fff95fe0440-00007fff95fe1900 [ 5K 5K 5K 0K] rw-/rwx SM=COW /usr/lib/system/libcommonCrypto.dylib
__DATA 00007fff95fe1900-00007fff95fe29a0 [ 4K 4K 4K 0K] rw-/rwx SM=COW /usr/lib/system/libcompiler_rt.dylib
__DATA 00007fff95fe29a0-00007fff95fe3090 [ 1776 1776 1776 0K] rw-/rwx SM=COW /usr/lib/system/libcopyfile.dylib
__DATA 00007fff95fe3090-00007fff95febab0 [ 35K 31K 11K 0K] rw-/rwx SM=COW /usr/lib/system/libcorecrypto.dylib
unused shlib __DATA 00007fff95febab0-00007fff95fec000 [ 1360 1360 1360 0K] rw-/rwx SM=COW unused system shared lib __DATA, on dirty page
Really? It's mapping sub-page-sized segments onto the same page? Wow.