Use statically allocated shadow on 32-bit OSX

[GoogleCodeExporter]

Debug builds of large Chromium tests for 32-bit OSX (including iossim builds) 
fail at startup, because one of the libraries accidentally occupies the shadow 
address space:

==23488==Shadow memory range interleaves with an existing memory mapping. ASan 
cannot proceed correctly. ABORTING.
==23488==Process memory map follows:
    0x21345000-0x21386000   /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/System/Library/PrivateFrameworks/ContentIndex.framework/ContentIndex
    0x21386000-0x21389000   /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/System/Library/PrivateFrameworks/ContentIndex.framework/ContentIndex
    0x21389000-0x213a1000   /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/System/Library/PrivateFrameworks/ContentIndex.framework/ContentIndex

This shouldn't be an issue on 64-bit OSX, since the address space is 
significantly larger.

We may want to statically link the 32-bit ASan binaries with a shadow section 
of proper size and location, at least in some cases. In the presence of this 
section the runtime should not attempt to map the shadow memory.

Original issue reported on code.google.com by ramosian.glider@gmail.com on 19 Jul 2013 at 3:28

[GoogleCodeExporter]

Original comment by gli...@chromium.org on 19 Jul 2013 at 3:33

[GoogleCodeExporter]

FYI I'm having a similar issue when building an iOS app + ASAN for the 64-bit 
iOS simulator 7.0.

Original comment by mathieu....@gmail.com on 19 Dec 2013 at 8:22

[GoogleCodeExporter]

Mathieu, is that a 32-bit iOS app on top of a 64-bit iOS simulator? I'd be 
surprised to see shadow memory overlapping for a 64-bit app.

Original comment by ramosian.glider@gmail.com on 24 Dec 2013 at 8:53

[GoogleCodeExporter]

Yes actually the app is still using 32bits pointers when run in the 
64bit-simulator. Sorry :)

Original comment by mathieu....@gmail.com on 9 Jan 2014 at 8:54

[GoogleCodeExporter]

Mathieu and I came up with a solution for this. Solution is simply moving the 
shadow address range 

from: 0x20000000 - 0x40000000
to: 0x40000000 - 0x60000000 

for 32bit Mac OS X binaries. I'm attaching the patch that helped us. To patch 
the actual code base we need the new constant managed by macros etc. though. So 
it'd be great if someone from project maintainers could advise us.

Note1: We had ASLR turned off during our testing.
Note2: We also had to turn globals check off since when it's on it's creating 
false positives and we're unable to run the process in a meaningful way. Is 
this a known issue?

Original comment by tahabeki...@gmail.com on 7 Mar 2014 at 9:20

Attachments:

• asan_shadow_patch.txt

[GoogleCodeExporter]

I've landed the patch changing the shadow memory mapping for iOS as you propose 
(r207002), this seems to help.
On a second thought we might really need the same change for 32-bit OSX, I'll 
test and submit it tommorrow.

Original comment by ramosian.glider@gmail.com on 23 Apr 2014 at 5:28

[GoogleCodeExporter]

Issue 38 has been merged into this issue.

Original comment by ramosian.glider@gmail.com on 7 May 2014 at 9:02

[GoogleCodeExporter]

For the record the OSX bits haven't been submitted. Still unclear whether we 
need them.

Original comment by ramosian.glider@gmail.com on 24 Jun 2014 at 1:32

[GoogleCodeExporter]

Original comment by ramosian.glider@gmail.com on 30 Jul 2015 at 9:05

• Added labels: ProjectAddressSanitizer

[GoogleCodeExporter]

Adding Project:AddressSanitizer as part of GitHub migration.

Original comment by ramosian.glider@gmail.com on 30 Jul 2015 at 9:06