false negative: access to 0x20 not reported

Dr. Memory is failing to report an unaddressable access for a small app
with a deref of an uninitialized pointer on Mac.

On Linux it's as expected:
```
$ ../../releases/DrMemory-Linux-2.2.0-1/bin64/drmemory -- ./a.out
~~Dr.M~~ Dr. Memory version 2.2.0
~~Dr.M~~
~~Dr.M~~ Error #1: UNADDRESSABLE ACCESS: reading 0x0000000000000020-0x0000000000000028 8 byte(s)
~~Dr.M~~ # 0 repair<> [/work/drmemory/bugs/segfault-noerror/DEBUG_ME.cpp:158]
~~Dr.M~~ # 1 main [/work/drmemory/bugs/segfault-noerror/DEBUG_ME.cpp:189]
~~Dr.M~~ Note: @0:00:01.394 in thread 3769
~~Dr.M~~ Note: instruction: mov 0x20(%rax) -> %rdx
```

But on Mac the error is not reported.

The seg fault is to the same address 0x20:
```
considering to-be-translated instr: mov 0x20(%rax)[8byte] -> %rax
SIGSEGV @0x0000000127137786 (xl8=>0x0000000107e32a1e) accessing 0x0000000000000020
signal interrupted app at xsp=0x00007ffee7dcd850
in event_thread_exit() 1365206
```

Somehow it's adding low addresses as app segments!
```
add new app segment for [0x0000000000000018, 0x0000000000000020)
```

Context:
```
in event_basic_block(tag=0x0000000117693732)
TAG 0x0000000117693732
+0 L3 65 8b 0c 25 18 00 00 mov %gs:0x18[4byte] -> %ecx
00
+8 L3 31 c0 xor %eax %eax -> %eax
+10 L3 f0 0f b1 0f lock cmpxchg %ecx (%rdi)[4byte] %eax -> (%rdi)[4byte] %eax
+14 L3 0f 85 01 00 00 00 jnz $0x0000000117693747
END 0x0000000117693732

new basic block @0x0000000117693732 == dyld!_os_nospin_lock_lock+0x0
whole-bb scratch: r1=%rdxspill#0 x0, r2=%rbxspill#1 x0
fastpath: mov %gs:0x18[4byte] -> %ecx| prop=1 srcsz=4 dstsz=4 checkdef=0 markdef=0 checkunaddr=0
fastpath: xor %eax %eax -> %eax| prop=0 srcsz=4 dstsz=4 checkdef=0 markdef=1 checkunaddr=0
fastpath: lock cmpxchg %ecx (%rdi)[4byte] %eax -> (%rdi)[4byte] %eax| prop=3 srcsz=4 dstsz=4 checkdef=1 markdef=0 checkunaddr=0
fastpath: jnz $0x0000000117693747| prop=0 srcsz=3 dstsz=0 checkdef=1 markdef=0 checkunaddr=0
whole-bb scratch: r1=used, r2=used, efl=used
in event_basic_block(tag=0x0000000117693732) translating
TAG 0x0000000117693732
+0 L3 65 8b 0c 25 18 00 00 mov %gs:0x18[4byte] -> %ecx
00
+8 L3 31 c0 xor %eax %eax -> %eax
+10 L3 f0 0f b1 0f lock cmpxchg %ecx (%rdi)[4byte] %eax -> (%rdi)[4byte] %eax
+14 L3 0f 85 01 00 00 00 jnz $0x0000000117693747
END 0x0000000117693732

whole-bb scratch: r1=%rdxspill#0 x0, r2=%rbxspill#1 x0
fastpath: mov %gs:0x18[4byte] -> %ecx| prop=1 srcsz=4 dstsz=4 checkdef=0 markdef=0 checkunaddr=0
fastpath: xor %eax %eax -> %eax| prop=0 srcsz=4 dstsz=4 checkdef=0 markdef=1 checkunaddr=0
fastpath: lock cmpxchg %ecx (%rdi)[4byte] %eax -> (%rdi)[4byte] %eax| prop=3 srcsz=4 dstsz=4 checkdef=1 markdef=0 checkunaddr=0
fastpath: jnz $0x0000000117693747| prop=0 srcsz=3 dstsz=0 checkdef=1 markdef=0 checkunaddr=0
whole-bb scratch: r1=used, r2=used, efl=used
event_restore_state: raw pc=0x0000000126d6980f, xl8 pc=0x0000000117693732, tag=0x0000000117693732
translated eflags from 0x0000000000010206 to 0x0000000000010202
restoring per-bb rdx to 0x0000000000000307
restoring per-bb rbx to 0x00007ffee7dcc540
considering to-be-translated instr: movzx (%rdx)[1byte] -> %rbx
add new app segment for [0x0000000000000018, 0x0000000000000020)
```

The movzx is just a lazy shadow memory init fault. However, lldb is just a
broken debugger: it goes into an infinite loop and can't go past the fault,
making this a pain to debug. (I tried to build my own lldb with a fix for
that but never got it to build in xcode...thanks, Apple, for terrible
debugger support.)