Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use statically allocated shadow on 32-bit OSX #210

Closed
ramosian-glider opened this issue Aug 31, 2015 · 11 comments
Closed

Use statically allocated shadow on 32-bit OSX #210

ramosian-glider opened this issue Aug 31, 2015 · 11 comments
Labels
OpSys-OSX Priority-Medium ProjectAddressSanitizer Status-Accepted Type-Enhancement

Comments

@ramosian-glider
Copy link
Member

Originally reported on Google Code with ID 210

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.

Reported by ramosian.glider on 2013-07-19 15:28:59
@ramosian-glider
Copy link
Member Author

Reported by glider@chromium.org on 2013-07-19 15:33:28

  • Blocking: #238398

@ramosian-glider
Copy link
Member Author 

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

Reported by mathieu.baudet on 2013-12-19 20:22:43

@ramosian-glider
Copy link
Member Author 

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.

Reported by ramosian.glider on 2013-12-24 08:53:36

@ramosian-glider
Copy link
Member Author 

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

Reported by mathieu.baudet on 2014-01-09 20:54:16

@ramosian-glider
Copy link
Member Author 

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?

Reported by tahabekireren on 2014-03-07 21:20:28

- _Attachment: [asan_shadow_patch.txt](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-210/comment-5/asan_shadow_patch.txt)_

@ramosian-glider
Copy link
Member Author 

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.

Reported by ramosian.glider on 2014-04-23 17:28:12

@ramosian-glider
Copy link
Member Author 

Issue 38 has been merged into this issue.

Reported by ramosian.glider on 2014-05-07 09:02:10

@ramosian-glider
Copy link
Member Author 

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

Reported by ramosian.glider on 2014-06-24 13:32:13

@ramosian-glider
Copy link
Member Author

Reported by ramosian.glider on 2015-07-30 09:05:31

  • Labels added: ProjectAddressSanitizer

@ramosian-glider
Copy link
Member Author 

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:06:55

@ramosian-glider
Copy link
Member Author

32-bit builds are of less importance now, let Apple engineers deal with this bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
OpSys-OSX Priority-Medium ProjectAddressSanitizer Status-Accepted Type-Enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ramosian-glider