MAP_32BIT doesn't work on x64 with TSAN

[GoogleCodeExporter]

Hi I've managed to build and run everything now with tsan, but I'm blocked by a 
problem that I've tracked down to how tsan intercepts mmap. It seems it doesn't 
support MAP_32BIT. Usually that's not a big deal because it's not an often used 
flag. However, luajit uses MAP_32BIT on x64 for all allocations. Here's a 
sample program that demonstrates the problem:

#include <sys/mman.h>
#include <iostream>

int main()
{
    void *ptr = mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_32BIT|MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
    std::cout << ptr << std::endl;    
    return 0;
}

Is this a show stopper, or could support be added for this? I'd be happy to do 
the work if someone pointed me in the right direction.

Cheers,
Dan

Original issue reported on code.google.com by dan.el...@gmail.com on 13 Nov 2012 at 9:31

[GoogleCodeExporter]

tsan can not support MAP_32BIT, sorry. 
This is not because tsan intercepts mmap, but because it mprotects the lower 
part of address space (the same reason why it requires -pie). 
Fixing this is not trivial and is not in our plans for any foreseeable future. 

I am not closing this bug now because I want to understand how big a problem 
this is.
Will be collecting other cases here. 

Original comment by konstant...@gmail.com on 14 Nov 2012 at 2:42

[GoogleCodeExporter]

Ok, thanks. Fixing luajit is also non-trivial because it uses 32-bit pointers 
everywhere, but I think I can work around this by disabling the lua parts of 
the application when running under tsan. Does the valgrind thread sanitizer 
have this same limitation?

Original comment by dan.el...@gmail.com on 14 Nov 2012 at 3:04

[GoogleCodeExporter]

>> Fixing luajit is also non-trivial because it uses 32-bit pointers everywhere,
Yea, understood. 

>> Does the valgrind thread sanitizer have this same limitation?
It shouldn't, as it uses slow but less restrictive shadow mapping. 

Original comment by konstant...@gmail.com on 15 Nov 2012 at 5:48

[GoogleCodeExporter]

I think it's possible to make tsan2 support MAP_32BIT.
The mapping for tsan2 is not the way it was designed originally (all addresses 
are 0x7f...) for a long time. In the COMPAT mode there are 4 user memory 
regions -- main stack at 0x7f..., heap at 0x7c... and modules at either 0x2a... 
or 0x2b...). The mapping for Go is also completely different and supports 2 
regions. I believe it's possible to support low 4 gigs for normal mapping as 
well.

Original comment by dvyu...@google.com on 15 Nov 2012 at 6:04

[GoogleCodeExporter]

If we can do it with little performance loss, why not.
unlike asan and msan, the shadow mapping is not the major hotspot, 
so maybe you are right. 

Does this mean that we can also drop the requirement for -pie? 

Original comment by konstant...@gmail.com on 15 Nov 2012 at 6:07

[GoogleCodeExporter]

There is no performance loss in COMPAT mode.
It may be possible to drop -pie as well. I am not sure right now.

Original comment by dvyu...@google.com on 15 Nov 2012 at 6:14

[GoogleCodeExporter]

Hi!
Are there any news on this?
Is there any possibility to allocate memory within 32bit address range?
Thanks!

Original comment by i...@unity3d.com on 10 Jun 2014 at 12:12

[GoogleCodeExporter]

Hi!

This functionality is not very trivial to support in tsan. I will make another 
try on this in month or so, but no promises now.

What is your use case? Why do you need to allocate memory in the 32-bit range?

Original comment by dvyu...@google.com on 10 Jun 2014 at 1:49

[GoogleCodeExporter]

I tried to sanitize code that depends on Mono and stumbled upon that mmap flag 
mono uses when allocating memory for jit generated code on linux64. But further 
investigation showed that there is way to build mono without depending on it 
(by defining MONO_ARCH_NOMAP32BIT).
So thank you, but if you have more interesting things to do, don't waste your 
time :).

Original comment by i...@ikseek.com on 11 Jun 2014 at 7:11

[GoogleCodeExporter]

Thanks for the info!
We will be happy to hear about your positive/negative experiences with 
tsan/mono. We never tried it, and I guess mono is a quite special program, so 
there are chances you will hit other systems issues with tsan.

Original comment by dvyu...@google.com on 11 Jun 2014 at 7:50

[GoogleCodeExporter]

Not sure whether it's still relevant, but fixed by rev 220571.

Original comment by dvyu...@google.com on 24 Oct 2014 at 5:18

• Changed state: Fixed

[GoogleCodeExporter]

Adding Project:ThreadSanitizer as part of GitHub migration.

Original comment by gli...@google.com on 30 Jul 2015 at 9:21

• Added labels: ProjectThreadSanitizer