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.

Sign up for GitHub

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

FB10/LLVM/CLANG3.5: Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. #303

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

FB10/LLVM/CLANG3.5: Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. #303

ramosian-glider opened this issue Aug 31, 2015 · 12 comments
Labels
OpSys-FreeBSD Priority-Medium ProjectAddressSanitizer Status-New Type-Defect

Comments

@ramosian-glider
Copy link
Member

Originally reported on Google Code with ID 303

What steps will reproduce the problem?

1.
Create a file test.c:

#include <stdio.h>
#include <stdlib.h>
int main(void){
        char * _b=(char*)calloc(1,20);
        free(_b);
        return (0);
}


2. compile
clang -fsanitize=address -O0 -fno-omit-frame-pointer -g3 test.c -o test

3. run ./test

and this is what I get:
==5969==Shadow memory range interleaves with an existing memory mapping. ASan cannot
proceed correctly. ABORTING.
==5969==Process memory map follows:
    0x000000400000-0x000000457000   /tmp/devel/lab/src/test
    0x000000656000-0x000000657000   /tmp/devel/lab/src/test
    0x000000657000-0x000001290000   
    0x000800656000-0x000800670000   /libexec/ld-elf.so.1
    0x000800670000-0x000800695000   
    0x000800695000-0x000800698000   
    0x00080069b000-0x00080069d000   
    0x00080086f000-0x000800871000   
    0x000800871000-0x00080087e000   /lib/libgcc_s.so.1
    0x00080087e000-0x000800a7d000   
    0x000800a7d000-0x000800a7e000   /lib/libgcc_s.so.1
    0x000800a7e000-0x000800be2000   /lib/libc.so.7
    0x000800be2000-0x000800de2000   
    0x000800de2000-0x000800dee000   /lib/libc.so.7
    0x000800dee000-0x000800e17000   
    0x000800e17000-0x000800e30000   /lib/libthr.so.3
    0x000800e30000-0x00080102f000   
    0x00080102f000-0x000801031000   /lib/libthr.so.3
    0x000801031000-0x00080103c000   
    0x00080103c000-0x000801041000   /usr/lib/librt.so.1
    0x000801041000-0x000801241000   
    0x000801241000-0x000801242000   /usr/lib/librt.so.1
    0x000801242000-0x000801267000   /lib/libm.so.5
    0x000801267000-0x000801467000   
    0x000801467000-0x000801468000   /lib/libm.so.5
    0x000801800000-0x000801c00000   
    0x7fffffbfe000-0x7fffffbff000   
    0x7ffffffdf000-0x7ffffffff000   
    0x7ffffffff000-0x800000000000   
==5969==End of process memory map.


What version of the product are you using? On what operating system?

I'm trying to compile llvm/clang 3.5 from source (svn), on FreeBSD 10.0-RELEASE-p1
GENERIC amd64
autoconf-2.69
autoconf-wrapper-20131203
automake-1.14
automake-wrapper-20131203
cmake-2.8.12.1_4
cmake-modules-2.8.12.1_1
gmake-3.82_1
libtool-2.4.2_2
llvm33-3.3_8 
m4-1.4.17_1,1
perl5-5.16.3_9 
python27-2.7.6_4

Reported by mr.codepot on 2014-04-30 08:44:35
@ramosian-glider
Copy link
Member Author 

forget to mention that to run this test I'm using this freshly compiled clang 3.5

Reported by mr.codepot on 2014-04-30 08:47:59

@ramosian-glider
Copy link
Member Author 

We do not support FreeBSD ourselves, let me contact the folks who did the FreeBSD port

Reported by konstantin.s.serebryany on 2014-04-30 08:50:06

  • Labels added: OpSys-FreeBSD

@ramosian-glider
Copy link
Member Author 

Unfortunately the compiler-rt is not included in the version of the llvm included/used
in the ports (llvm-3.5.r203994). That is why I used the original source code from svn.

Also I don't know if this has anything to do with it but I'm running this test machine
on vmware host.

Reported by mr.codepot on 2014-04-30 14:37:21

@ramosian-glider
Copy link
Member Author 

Please note that adding FreeBSD support for sanitizers is still in progress. Currently,
by 'check-all' we pass the common tests with no unexpected failures and the next thing
to do is to pass Asan tests. By conincidence, the process memory mapping is what we
are working on these days, so soon there should be a patch put on review that address
this specific issue with interleaving memory regions.

Reported by kutuzov.viktor.84 on 2014-05-05 08:19:31

@ramosian-glider
Copy link
Member Author

Reported by konstantin.s.serebryany on 2014-05-06 08:36:10

@ramosian-glider
Copy link
Member Author 

Thank you for the reply/information. 

Please let me know when you will have any working version - I'll gladly test it.

Reported by mr.codepot on 2014-05-06 11:55:19

@ramosian-glider
Copy link
Member Author 

I have thi sissue on Linux 64bit.

g++ ./app.cpp -O0 --std=c++0x -pthread -Wall -fsanitize=address -fno-omit-frame-pointer

Reported by ColinTrexob on 2014-07-23 16:44:35

@ramosian-glider
Copy link
Member Author 

With this kernel patch applied:

http://reviews.llvm.org/D3732#21

and this clang patch applied:

http://reviews.llvm.org/D4623

the latest revisions should pass Asan tests on FreeBSD 9.2 without unexpected failures.
It's also known that at least one of the recent revisions does work on FreeBSD 10.0
with a couple minor changes.

Reported by kutuzov.viktor.84 on 2014-08-09 11:34:13

@ramosian-glider
Copy link
Member Author 

r218042 pass Asan test without unexpected failures on FreeBSD 10.0 with the /usr/src/sys/kern/kern_proc.c
file patched and the kern.proc_vmmap_skip_resident_count kernel state set to 1. Attached
are the patched and original versions of the source file.

Reported by kutuzov.viktor.84 on 2014-09-22 06:32:49

- _Attachment: [kern_proc.c](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-303/comment-10/kern_proc.c)_ - _Attachment: [kern_proc.c.original](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-303/comment-10/kern_proc.c.original)_

@ramosian-glider
Copy link
Member Author

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

  • 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:56

@kcc
Copy link
Contributor

kcc commented Dec 1, 2015

Not dealing with FreeBSD here.

@kcc kcc closed this as completed Dec 1, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
OpSys-FreeBSD Priority-Medium ProjectAddressSanitizer Status-New Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ramosian-glider @kcc