search

gopalshankar / address-sanitizer

Automatically exported from code.google.com/p/address-sanitizer
0 stars 0 forks source link

Allocator [v2] works badly on 32-bit archs? #165

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
This is what I get when running a fresh RTL with allocator v2 on Chromium 
net_unittests:

==9580== AddressSanitizer CHECK failed: ../sanitizer_common/sanitizer_win.cc:67 
"(("unable to mmap" && 0)) != (0)" (0x0, 0x0)
Stats: 548M malloced (55M for red zones) by 2114721 calls
Stats: 42M realloced by 10269 calls
Stats: 544M freed by 2084518 calls
Stats: 481M really freed by 1608892 calls
==9580== ERROR: Failed to allocate 0x4000 (16384) bytes of InternalScopedBuffer

Looking at the process info in Process Explorer, it shows 938.8MB used out of 
2GB available for the process.
I'd expect a reasonable allocation strategy / size classes to not OOM at 45% 
address space utilization.

// Please note however that net_unittests have never worked with allocator v1, 
OOMing at 2GB (100% address space utilization).

[+cc Evgeniy who has observed some issues when switching Android to v2]

Original issue reported on code.google.com by timurrrr@google.com on 1 Mar 2013 at 3:42

GoogleCodeExporter commented 9 years ago 
I've augmented the stats printer to print out the actual MBs consumed by each 
class.

--gtest_filter="-DirectoryListerTest.BigDirRecursiveTest":
==7424== ERROR: Failed to allocate 0x184000 (1'589'248) bytes of 
__asan::AsanThread::Create
Stats: 544M malloced (54M for red zones) by 2111203 calls
Stats: 42M realloced by 10269 calls
Stats: 540M freed by 2080914 calls
Stats: 479M really freed by 1608204 calls
Stats: 291M (619M-328M) mmaped; 1231 maps, 886 unmaps
(Process Explorer shows 935.6MB consumed)
  mmaps   by size class:
  mallocs by size class: 2:136923; 3:1378268 (63MB); 4:165592 (10MB); 6:113716 (10MB); 7:41108; 8:14175; 11:12453; 12:20012; 13:23307; 14:7663; 15:16459; 16:892
4; 17:16075; 18:105727
// Showing only 1MB+ classes

--gtest_filter="DirectoryListerTest.BigDirRecursiveTest", mallocs by size class:
==2152== ERROR: Failed to allocate 0x22b8000 (36'405'248) bytes of 
LargeMmapAllocator
Stats: 1752M malloced (429M for red zones) by 7537987 calls
Stats: 0M realloced by 15 calls
Stats: 1633M freed by 7374776 calls
Stats: 1598M really freed by 7318109 calls
Stats: 586M (853M-266M) mmaped; 511 maps, 29 unmaps
(Process Explorer shows 1.1GB consumed)
  mmaps   by size class:
  mallocs by size class: 13:385883 (76MB); 14:738631 (157MB); 15:737061 (168MB); 16:1191171 (290MB); 17:1093142 (300MB); 18:1205876 (368MB); 19:743510 (249MB); 20:145264 (53MB);
// Showing only 50MB+ classes

Original comment by timurrrr@google.com on 1 Mar 2013 at 4:41

Attachments:

GoogleCodeExporter commented 9 years ago 
(frees: and rfrees: are always empty)

Original comment by timurrrr@google.com on 1 Mar 2013 at 4:42

GoogleCodeExporter commented 9 years ago 
Since
http://llvm.org/viewvc/llvm-project?view=revision&revision=186393
I've lowered the shadow vmemory usage by 256MB, but the problem is still there, 
hitting the roof at 726.1MB

Original comment by timurrrr@google.com on 16 Jul 2013 at 10:58

GoogleCodeExporter commented 9 years ago 
Good news: DirectoryListerTest.BigDirRecursiveTest alone now passes fine.

Original comment by timurrrr@google.com on 16 Jul 2013 at 10:59