[llvm-testresults] buildbot failure in lab.llvm.org on phase2 - living

[llvmlab-buildmaster at lab.llvm.org]

The Buildbot has detected a new failure on builder phase2 - living while building lab.llvm.org.
Full details are available at:
 http://lab.llvm.org:8013/builders/phase2%20-%20living/builds/7401

Buildbot URL: http://lab.llvm.org:8013/

Buildslave for this Build: macpro1

Build Reason: scheduler
Build Source Stamp: 204994
Blamelist: chandlerc,eugenis

BUILD FAILED: failed

sincerely,
 -The Buildbot


================================================================================

CHANGES:
Files:
 lib/sanitizer_common/sanitizer_common_interceptors.inc
 lib/sanitizer_common/sanitizer_platform_interceptors.h
 lib/sanitizer_common/sanitizer_platform_limits_posix.cc
 lib/sanitizer_common/sanitizer_platform_limits_posix.h
 test/msan/ftime.cc
On: smooshlab-project
At: Fri 28 Mar 2014 01:41:45
Changed By: eugenis
Comments: [sanitizer] Intercept ftime.
Properties: 
  phase_id: r204991-t20140328_014345-b18515



File: lib/ExecutionEngine/JIT/JITMemoryManager.cpp
On: smooshlab-project
At: Fri 28 Mar 2014 02:01:45
Changed By: chandlerc
Comments: [cleanup] Hoist the initialization and constants for slab sizes to the
top of the default jit memory manager. This will allow them to be used
as template parameters rather than runtime parameters in a subsequent
commit.Properties: 
  phase_id: r204993-t20140328_020346-b18516



Files:
 include/llvm/Support/Allocator.h
 lib/Support/Allocator.cpp
On: smooshlab-project
At: Fri 28 Mar 2014 02:01:45
Changed By: chandlerc
Comments: [Allocator Cleanup] Make the growth of the "slab" size of the
BumpPtrAllocator significantly less strange by making it a simple
function of the number of slabs allocated rather than by making it
a recurrance. I *think* the previous behavior was essentially that the
size of the slabs would be doubled after the first 128 were allocated,
and then doubled again each time 64 more were allocated, but only if
every allocation packed perfectly into the slab size. If not, the wasted
space wouldn't be counted toward increasing the size, but allocations
over the size threshold *would*. And since the allocations over the size
threshold might be much larger than the slab size, this could have
somewhat surprising consequences where we rapidly grow the slab size.

This currently requires adding state to the allocator to track the
number of slabs currently allocated, but that isn't too bad. I'm
planning further changes to the allocator that will make this state fall
out even more naturally.

It still doesn't fully decouple the growth rate from the allocations
which are over the size threshold. That fix is coming later.

This specific fix will allow making the entire thing into a more
stateless device and lifting the parameters into template parameters
rather than runtime parameters.Properties: 
  phase_id: r204993-t20140328_020346-b18516



Files:
 lib/sanitizer_common/sanitizer_common_interceptors.inc
 test/msan/mktime.cc
On: smooshlab-project
At: Fri 28 Mar 2014 02:11:45
Changed By: eugenis
Comments: [sanitizer] Intercept mktime.
Properties: 
  phase_id: r204994-t20140328_023345-b18517



LOGS: