MAP_32BIT doesn't work on x64 with TSAN

[ramosian-glider]

Originally reported on Google Code with ID 5

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

Reported by dan.eloff on 2012-11-13 21:31:15

[ramosian-glider]

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. 

Reported by konstantin.s.serebryany on 2012-11-14 02:42:02

[ramosian-glider]

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?

Reported by dan.eloff on 2012-11-14 03:04:00

[ramosian-glider]

>> 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. 

Reported by konstantin.s.serebryany on 2012-11-15 17:48:32

[ramosian-glider]

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.

Reported by dvyukov@google.com on 2012-11-15 18:04:29

[ramosian-glider]

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? 

Reported by konstantin.s.serebryany on 2012-11-15 18:07:37

[ramosian-glider]

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

Reported by dvyukov@google.com on 2012-11-15 18:14:07

[ramosian-glider]

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

Reported by igor@unity3d.com on 2014-06-10 12:12:17

[ramosian-glider]

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?

Reported by dvyukov@google.com on 2014-06-10 13:49:32

[ramosian-glider]

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
:).

Reported by igor@ikseek.com on 2014-06-11 19:11:18

[ramosian-glider]

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.

Reported by dvyukov@google.com on 2014-06-11 19:50:40

[ramosian-glider]

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

Reported by dvyukov@google.com on 2014-10-24 17:18:27

• Status changed: Fixed

[ramosian-glider]

Adding Project:ThreadSanitizer as part of GitHub migration.

Reported by glider@google.com on 2015-07-30 09:21:29

• Labels added: ProjectThreadSanitizer

[ramosian-glider]

hi i am looking to run tsan in my ARMv7 32 bit architecture. i have 2 queries.

1. Is the "difficulty for running in 32-bit architecture" because of the Physical Address
Extension (PAE) and because of simplicity of use it does not support 32 bits?

2. if i need to port it into 32 bit ARM, is it possible?, if it is possible do i need
to do anything else along with porting "tsan_rtl_amd64.S" assembly code to ARM assemble
code?
any help will be appreciated . thanks.  

Reported by arunabhankit on 2015-08-20 16:09:15

[ramosian-glider]

Hi arunabhankit,

Please write to thread-sanitizer@googlegroups.com news groups. This bug is closed long
ago and is unrelated.

Reported by dvyukov@google.com on 2015-08-20 16:16:07